This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: recent binutils and mips64-linux


On Thu, Oct 02, 2003 at 08:14:15PM +0200, Maciej W. Rozycki wrote:
> On 24 Sep 2003, Richard Sandiford wrote:
> 
> > Right.  Have I understood correctly, and that all we want is a way to
> > generate n64 code in which symbols are known to have 32-bit values?
> > If so, it should just be a case of disabling:
> > 
> >   /* -mexplicit-relocs doesn't yet support non-PIC n64.  We don't know
> >      how to generate %highest/%higher/%hi/%lo sequences.  */
> >   if (mips_abi == ABI_64 && !TARGET_ABICALLS)
> >     {
> >       if ((target_flags_explicit & target_flags & MASK_EXPLICIT_RELOCS) != 0)
> > 	sorry ("non-PIC n64 with explicit relocations");
> >       target_flags &= ~MASK_EXPLICIT_RELOCS;
> >     }
> > 
> > when this new command-line flag is passed.  We'll then generate the
> > normal %hi/%lo sequences instead of dla.  I'll drum up a patch.
> 
>  Note that the resulting object file should be somehow marked to let a
> user know it has some addressing restrictions and cannot be linked at an
> arbitrary address.
> 
>  Actually the best solution might be using ELF32 (possibly n32) for the
> output format, which automatically guarantees a 32-bit address space, but
> use an n64 setup for the gcc's code generator.  This way no change is
> needed to binutils at all. 

This makes GDB extremely unhappy.  Probably other tools too.  Please
leave the ABI markings to represent the calling conventions used by the
program, instead of overloading them for this.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]