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: how close to binutils-2.12 previews


On Fri, 15 Feb 2002, Thiemo Seufer wrote:

> >  But you can't express all relocations that are needed by "dla".
> 
> Dream a moment of n32 ABI, where the relocations are available. :-)

 Hmm, what for?  Or if there is a reason, objects should use ELF64, then. 
You need a 64-bit file format for objects defining 64-bit symbols.  For
objects defining 32-bit symbols only you may use a 32-bit object.

 The reason is simple -- a 32-bit ELF file does not provide space in its
structures needed for high 32 bits of addresses.  A conversion from the
64-bit format to the 32-bit one, if permitted at all, truncates addresses
to low 32 bits -- the high ones are lost.

> > Also what would you need 64-bit addressing for in a 32-bit object?
> 
> Current MIPS64/Linux Kernels are exactly that.

 AFAIK the kernel doesn't really encode 64-bit addresses as immediate
values -- CKSEG0/CKSEG1 addresses do not need full 64-bit loads if values
are properly sign-extended.  And other addresses are only passed
indirectly.  Thus it does not need a 64-bit object.  The kernel is special
anyway.

> > None of
> > sections can lie outside the 32-bit address space, so you'll never get a
> > symbol that needs "dla" to take address of (IOW, a "dla" will always do
> > the same that a "la" but with more instructions).
> 
> What if you have an ARCS64 firmware bootvector outside the 32bit space...

 You can't express a 64-bit symbol in a 32-bit object.  You have the
32-bit address space.  If you have a boot vector outside the 32-bit space,
you need to hand-code its references anyway -- you can't use "la"/"dla" 
macros for this purpose. 

> Even the native SGI toolchain uses n32 as default: Better performance
> and still enough address space for most applications. Btw, I intend
> to change the default to a newly invented n32 vector RSN.

 That doesn't mean the default is right for Linux as well.  I'd prefer to
maximize capabilities by default and treat the address space clip as an
optional optimization flag.  Or we can define additional configure target
triplets.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +


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