x32 psABI draft version 0.2

x32 psABI draft version 0.2

[H.J. Lu]

Hi,

I updated  x32 psABI draft to version 0.2 to change x32 library path
from lib32 to libx32 since lib32 is used for ia32 libraries on Debian,
Ubuntu and other derivative distributions. The new x32 psABI is
available from:

https://sites.google.com/site/x32abi/home


-- 
H.J.

Re: x32 psABI draft version 0.2

[H. Peter Anvin]

On 02/16/2011 11:22 AM, H.J. Lu wrote:
> Hi,
> 
> I updated  x32 psABI draft to version 0.2 to change x32 library path
> from lib32 to libx32 since lib32 is used for ia32 libraries on Debian,
> Ubuntu and other derivative distributions. The new x32 psABI is
> available from:
> 
> https://sites.google.com/site/x32abi/home
> 

I'm wondering if we should define a section header flag (sh_flags)
and/or an ELF header flag (e_flags) for x32 for the people unhappy about
keying it to the ELF class...

	-hpa

Re: x32 psABI draft version 0.2

[Roland McGrath]

> I'm wondering if we should define a section header flag (sh_flags)
> and/or an ELF header flag (e_flags) for x32 for the people unhappy about
> keying it to the ELF class...

I don't see what's wrong with paying attention to the class.  IMHO sh_flags
only makes sense if you might ever mix x32 and normal x86_64 code together
in one link, in which case indeed neither class alone nor anything else
file-global is sufficient.  If you don't do that, e_flags seems redundant
when it's already unambiguous from the class, but I suppose it doesn't hurt.

The only other complaint I imagine is the weirdo case of 32-bit systems
that deliver ELFCLASS64 core dump files so they can have a full 4GB of
memory as well as the thread state notes, where perhaps you'd want
something in the core file's headers (e.g. e_flags) to distinguish x32 from
x86_64.  But it seems to me the actual core note layouts for x32 ought to
just be the x86_64 ones anyway, so it's hard to see really caring.


Thanks,
Roland

Re: x32 psABI draft version 0.2

[Chris Metcalf]

On 2/16/2011 3:04 PM, H. Peter Anvin wrote:
> On 02/16/2011 11:22 AM, H.J. Lu wrote:
>> Hi,
>>
>> I updated  x32 psABI draft to version 0.2 to change x32 library path
>> from lib32 to libx32 since lib32 is used for ia32 libraries on Debian,
>> Ubuntu and other derivative distributions. The new x32 psABI is
>> available from:
>>
>> https://sites.google.com/site/x32abi/home
> I'm wondering if we should define a section header flag (sh_flags)
> and/or an ELF header flag (e_flags) for x32 for the people unhappy about
> keying it to the ELF class...

For what it's worth, the Tilera 64-bit architecture (forthcoming) includes
support for a 32-bit compatibility layer that is similar to x32.  It uses
64-bit registers throughout (e.g. for double and long long), but 32-bit
addresses.  The addresses between 2GB and 4GB are not directly usable as
64-bit addresses since we sign-extend all 32-bit values to make the ISA
more straightforward.  We use the "compat" layer to provide our syscall
table, since we don't have a traditional compatibility layer in this mode
(unlike x86_64 and i386).

We differentiate the 64-bit and 32-bit binaries just by the Elf class, a
proposed by H.J. above.  This seems plausible given that it does capture
the differences correctly; everything else is the same, just the Elf
class.  (And we use /lib vs /lib32 on the 64-bit platform to support the
32-bit shared libraries, etc.)

-- 
Chris Metcalf, Tilera Corp.
http://www.tilera.com

Re: x32 psABI draft version 0.2

[Andrew Pinski]

On Wed, Feb 16, 2011 at 12:35 PM, Chris Metcalf <cmetcalf@tilera.com> wrote:
> For what it's worth, the Tilera 64-bit architecture (forthcoming) includes
> support for a 32-bit compatibility layer that is similar to x32.  It uses
> 64-bit registers throughout (e.g. for double and long long), but 32-bit
> addresses.  The addresses between 2GB and 4GB are not directly usable as
> 64-bit addresses since we sign-extend all 32-bit values to make the ISA
> more straightforward.  We use the "compat" layer to provide our syscall
> table, since we don't have a traditional compatibility layer in this mode
> (unlike x86_64 and i386).

This sounds more like MIPS' n32 than x32 really.

-- Pinski

Re: x32 psABI draft version 0.2

[H.J. Lu]

On Wed, Feb 16, 2011 at 12:39 PM, Andrew Pinski <pinskia@gmail.com> wrote:
> On Wed, Feb 16, 2011 at 12:35 PM, Chris Metcalf <cmetcalf@tilera.com> wrote:
>> For what it's worth, the Tilera 64-bit architecture (forthcoming) includes
>> support for a 32-bit compatibility layer that is similar to x32.  It uses
>> 64-bit registers throughout (e.g. for double and long long), but 32-bit
>> addresses.  The addresses between 2GB and 4GB are not directly usable as
>> 64-bit addresses since we sign-extend all 32-bit values to make the ISA
>> more straightforward.  We use the "compat" layer to provide our syscall
>> table, since we don't have a traditional compatibility layer in this mode
>> (unlike x86_64 and i386).
>
> This sounds more like MIPS' n32 than x32 really.
>

Yes, x32 can access the full 4GB address space.  There are some
additional optimizations which can be done in x32, but not in x86-64
small model.

-- 
H.J.

Re: x32 psABI draft version 0.2

[Chris Metcalf]

On 2/16/2011 3:46 PM, H.J. Lu wrote:
> On Wed, Feb 16, 2011 at 12:39 PM, Andrew Pinski <pinskia@gmail.com> wrote:
>> On Wed, Feb 16, 2011 at 12:35 PM, Chris Metcalf <cmetcalf@tilera.com> wrote:
>>> For what it's worth, the Tilera 64-bit architecture (forthcoming) includes
>>> support for a 32-bit compatibility layer that is similar to x32.  It uses
>>> 64-bit registers throughout (e.g. for double and long long), but 32-bit
>>> addresses.  The addresses between 2GB and 4GB are not directly usable as
>>> 64-bit addresses since we sign-extend all 32-bit values to make the ISA
>>> more straightforward.  We use the "compat" layer to provide our syscall
>>> table, since we don't have a traditional compatibility layer in this mode
>>> (unlike x86_64 and i386).
>> This sounds more like MIPS' n32 than x32 really.
>>
> Yes, x32 can access the full 4GB address space.  There are some
> additional optimizations which can be done in x32, but not in x86-64
> small model.

Just to be clear, the "-m32" mode in our 64-bit architecture can access the
full 4GB address space, but since "-m32" pointers are sign-extended in the
high 32 bits, the kernel/userspace boundary has to convert between a
sign-extended userspace pointer and a regular zero-extended pointer that
the kernel wants to see.

-- 
Chris Metcalf, Tilera Corp.
http://www.tilera.com

Re: x32 psABI draft version 0.2

[Jan Beulich]

>>> On 16.02.11 at 21:04, "H. Peter Anvin" <hpa@zytor.com> wrote:
> On 02/16/2011 11:22 AM, H.J. Lu wrote:
>> Hi,
>> 
>> I updated  x32 psABI draft to version 0.2 to change x32 library path
>> from lib32 to libx32 since lib32 is used for ia32 libraries on Debian,
>> Ubuntu and other derivative distributions. The new x32 psABI is
>> available from:
>> 
>> https://sites.google.com/site/x32abi/home 
>> 
> 
> I'm wondering if we should define a section header flag (sh_flags)
> and/or an ELF header flag (e_flags) for x32 for the people unhappy about
> keying it to the ELF class...

Thanks for supporting this!

Besides that I also wonder why all the 64-bit relocations get
marked as LP64-only. It is clear that some of them can be useful
in ILP32 as well, and there's no reason to preclude future uses
even if currently no-one can imagine any.

Furthermore, it seems questionable to continue to require rela
relocations when for all normal ones (leaving aside the 8- and 16-
bit ones) the addend can fit in the relocated field.

Finally, shouldn't R_X86_64_GLOB_DAT and R_X86_64_JUMP_SLOT
also have a field specifier of wordclass rather than word64 (though
'wordclass' by itself would probably be wrong if the tying of the ABI
to the ELF class was eliminated)? And how about R_X86_64_*TP*64
and R_X86_64_TLSDESC?

Jan

Re: x32 psABI draft version 0.2

[H.J. Lu]

On Thu, Feb 17, 2011 at 12:35 AM, Jan Beulich <JBeulich@novell.com> wrote:
>>>> On 16.02.11 at 21:04, "H. Peter Anvin" <hpa@zytor.com> wrote:
>> On 02/16/2011 11:22 AM, H.J. Lu wrote:
>>> Hi,
>>>
>>> I updated  x32 psABI draft to version 0.2 to change x32 library path
>>> from lib32 to libx32 since lib32 is used for ia32 libraries on Debian,
>>> Ubuntu and other derivative distributions. The new x32 psABI is
>>> available from:
>>>
>>> https://sites.google.com/site/x32abi/home
>>>
>>
>> I'm wondering if we should define a section header flag (sh_flags)
>> and/or an ELF header flag (e_flags) for x32 for the people unhappy about
>> keying it to the ELF class...
>
> Thanks for supporting this!

I am not convinced.

> Besides that I also wonder why all the 64-bit relocations get
> marked as LP64-only. It is clear that some of them can be useful
> in ILP32 as well, and there's no reason to preclude future uses
> even if currently no-one can imagine any.

We can revisit them when someone finds a use for them.

> Furthermore, it seems questionable to continue to require rela
> relocations when for all normal ones (leaving aside the 8- and 16-
> bit ones) the addend can fit in the relocated field.

Rela is much nicer to work with.

> Finally, shouldn't R_X86_64_GLOB_DAT and R_X86_64_JUMP_SLOT

Fixed in git.

> also have a field specifier of wordclass rather than word64 (though
> 'wordclass' by itself would probably be wrong if the tying of the ABI
> to the ELF class was eliminated)? And how about R_X86_64_*TP*64
> and R_X86_64_TLSDESC?

Those are 64bits due to the way the code sequence generated
by gcc.

-- 
H.J.

Re: x32 psABI draft version 0.2

[Jakub Jelinek]

On Thu, Feb 17, 2011 at 08:35:26AM +0000, Jan Beulich wrote:
> >>> On 16.02.11 at 21:04, "H. Peter Anvin" <hpa@zytor.com> wrote:
> > On 02/16/2011 11:22 AM, H.J. Lu wrote:
> >> Hi,
> >> 
> >> I updated  x32 psABI draft to version 0.2 to change x32 library path
> >> from lib32 to libx32 since lib32 is used for ia32 libraries on Debian,
> >> Ubuntu and other derivative distributions. The new x32 psABI is
> >> available from:
> >> 
> >> https://sites.google.com/site/x32abi/home 
> >> 
> > 
> > I'm wondering if we should define a section header flag (sh_flags)
> > and/or an ELF header flag (e_flags) for x32 for the people unhappy about
> > keying it to the ELF class...
> 
> Thanks for supporting this!
> 
> Besides that I also wonder why all the 64-bit relocations get
> marked as LP64-only. It is clear that some of them can be useful
> in ILP32 as well, and there's no reason to preclude future uses
> even if currently no-one can imagine any.
> 
> Furthermore, it seems questionable to continue to require rela
> relocations when for all normal ones (leaving aside the 8- and 16-
> bit ones) the addend can fit in the relocated field.

REL is horrible pain, we shouldn't ever add new REL targets.

	Jakub

Re: x32 psABI draft version 0.2

[Jan Hubicka]

> On Thu, Feb 17, 2011 at 08:35:26AM +0000, Jan Beulich wrote:
> > >>> On 16.02.11 at 21:04, "H. Peter Anvin" <hpa@zytor.com> wrote:
> > > On 02/16/2011 11:22 AM, H.J. Lu wrote:
> > >> Hi,
> > >> 
> > >> I updated  x32 psABI draft to version 0.2 to change x32 library path
> > >> from lib32 to libx32 since lib32 is used for ia32 libraries on Debian,
> > >> Ubuntu and other derivative distributions. The new x32 psABI is
> > >> available from:
> > >> 
> > >> https://sites.google.com/site/x32abi/home 
> > >> 
> > > 
> > > I'm wondering if we should define a section header flag (sh_flags)
> > > and/or an ELF header flag (e_flags) for x32 for the people unhappy about
> > > keying it to the ELF class...
> > 
> > Thanks for supporting this!
> > 
> > Besides that I also wonder why all the 64-bit relocations get
> > marked as LP64-only. It is clear that some of them can be useful
> > in ILP32 as well, and there's no reason to preclude future uses
> > even if currently no-one can imagine any.
> > 
> > Furthermore, it seems questionable to continue to require rela
> > relocations when for all normal ones (leaving aside the 8- and 16-
> > bit ones) the addend can fit in the relocated field.
> 
> REL is horrible pain, we shouldn't ever add new REL targets.

According to Mozilla folks however REL+RELA scheme used by EABI leads
to significandly smaller libxul.so size

According to http://glandium.org/blog/?p=1177 the difference is about 4-5MB
(out of approximately 20-30MB shared lib)

Honza
> 
> 	Jakub

Re: x32 psABI draft version 0.2

[H.J. Lu]

On Thu, Feb 17, 2011 at 7:22 AM, Jan Hubicka <hubicka@ucw.cz> wrote:
>> On Thu, Feb 17, 2011 at 08:35:26AM +0000, Jan Beulich wrote:
>> > >>> On 16.02.11 at 21:04, "H. Peter Anvin" <hpa@zytor.com> wrote:
>> > > On 02/16/2011 11:22 AM, H.J. Lu wrote:
>> > >> Hi,
>> > >>
>> > >> I updated  x32 psABI draft to version 0.2 to change x32 library path
>> > >> from lib32 to libx32 since lib32 is used for ia32 libraries on Debian,
>> > >> Ubuntu and other derivative distributions. The new x32 psABI is
>> > >> available from:
>> > >>
>> > >> https://sites.google.com/site/x32abi/home
>> > >>
>> > >
>> > > I'm wondering if we should define a section header flag (sh_flags)
>> > > and/or an ELF header flag (e_flags) for x32 for the people unhappy about
>> > > keying it to the ELF class...
>> >
>> > Thanks for supporting this!
>> >
>> > Besides that I also wonder why all the 64-bit relocations get
>> > marked as LP64-only. It is clear that some of them can be useful
>> > in ILP32 as well, and there's no reason to preclude future uses
>> > even if currently no-one can imagine any.
>> >
>> > Furthermore, it seems questionable to continue to require rela
>> > relocations when for all normal ones (leaving aside the 8- and 16-
>> > bit ones) the addend can fit in the relocated field.
>>
>> REL is horrible pain, we shouldn't ever add new REL targets.
>
> According to Mozilla folks however REL+RELA scheme used by EABI leads
> to significandly smaller libxul.so size
>
> According to http://glandium.org/blog/?p=1177 the difference is about 4-5MB
> (out of approximately 20-30MB shared lib)

This is orthogonal to x32 psABI.



-- 
H.J.

Re: x32 psABI draft version 0.2

[Jan Hubicka]

> > According to Mozilla folks however REL+RELA scheme used by EABI leads
> > to significandly smaller libxul.so size
> >
> > According to http://glandium.org/blog/?p=1177 the difference is about 4-5MB
> > (out of approximately 20-30MB shared lib)
> 
> This is orthogonal to x32 psABI.

Understood.  I am just pointing out that x86-64 Mozilla suffers from startup
problems (extra 5MB of disk read needed) compared to both x86 and ARM EABI
because x86-64 ABI is RELA only. If x86-64 ABI was REL+RELA like EABI is, we
would not have this problem here.

Honza

Re: x32 psABI draft version 0.2

[H.J. Lu]

On Thu, Feb 17, 2011 at 7:44 AM, Jan Hubicka <hubicka@ucw.cz> wrote:
>> > According to Mozilla folks however REL+RELA scheme used by EABI leads
>> > to significandly smaller libxul.so size
>> >
>> > According to http://glandium.org/blog/?p=1177 the difference is about 4-5MB
>> > (out of approximately 20-30MB shared lib)
>>
>> This is orthogonal to x32 psABI.
>
> Understood.  I am just pointing out that x86-64 Mozilla suffers from startup
> problems (extra 5MB of disk read needed) compared to both x86 and ARM EABI
> because x86-64 ABI is RELA only. If x86-64 ABI was REL+RELA like EABI is, we
> would not have this problem here.
>

If people want to see REL+RELA in x32, they have to contribute codes.

-- 
H.J.

Re: x32 psABI draft version 0.2

[Jan Beulich]

>>> On 17.02.11 at 16:49, "H.J. Lu" <hjl.tools@gmail.com> wrote:
> On Thu, Feb 17, 2011 at 7:44 AM, Jan Hubicka <hubicka@ucw.cz> wrote:
>>> > According to Mozilla folks however REL+RELA scheme used by EABI leads
>>> > to significandly smaller libxul.so size
>>> >
>>> > According to http://glandium.org/blog/?p=1177 the difference is about 4-5MB
>>> > (out of approximately 20-30MB shared lib)
>>>
>>> This is orthogonal to x32 psABI.
>>
>> Understood.  I am just pointing out that x86-64 Mozilla suffers from startup
>> problems (extra 5MB of disk read needed) compared to both x86 and ARM EABI
>> because x86-64 ABI is RELA only. If x86-64 ABI was REL+RELA like EABI is, we
>> would not have this problem here.
>>
> 
> If people want to see REL+RELA in x32, they have to contribute codes.

That's exactly the wrong way round: First the specification has to allow
for (but not require) it, and only then does it make sense to write code.

Jan

Re: x32 psABI draft version 0.2

[John Reiser]

On 02/17/2011 04:14 AM, H.J. Lu wrote:
> On Thu, Feb 17, 2011 at 12:35 AM, Jan Beulich <JBeulich@novell.com> wrote:

>> Furthermore, it seems questionable to continue to require rela
>> relocations when for all normal ones (leaving aside the 8- and 16-
>> bit ones) the addend can fit in the relocated field.
> 
> Rela is much nicer to work with.

How is RELA much nicer to work with than REL?

-- 

Re: x32 psABI draft version 0.2

[H.J. Lu]

On Thu, Feb 17, 2011 at 8:11 AM, Jan Beulich <JBeulich@novell.com> wrote:
>>>> On 17.02.11 at 16:49, "H.J. Lu" <hjl.tools@gmail.com> wrote:
>> On Thu, Feb 17, 2011 at 7:44 AM, Jan Hubicka <hubicka@ucw.cz> wrote:
>>>> > According to Mozilla folks however REL+RELA scheme used by EABI leads
>>>> > to significandly smaller libxul.so size
>>>> >
>>>> > According to http://glandium.org/blog/?p=1177 the difference is about 4-5MB
>>>> > (out of approximately 20-30MB shared lib)
>>>>
>>>> This is orthogonal to x32 psABI.
>>>
>>> Understood.  I am just pointing out that x86-64 Mozilla suffers from startup
>>> problems (extra 5MB of disk read needed) compared to both x86 and ARM EABI
>>> because x86-64 ABI is RELA only. If x86-64 ABI was REL+RELA like EABI is, we
>>> would not have this problem here.
>>>
>>
>> If people want to see REL+RELA in x32, they have to contribute codes.
>
> That's exactly the wrong way round: First the specification has to allow
> for (but not require) it, and only then does it make sense to write code.
>

No, it has to be supported at least by static linker and dynamic
linker. Otherwise, no one can use it.

-- 
H.J.

Re: x32 psABI draft version 0.2

[Jakub Jelinek]

On Thu, Feb 17, 2011 at 08:13:55AM -0800, John Reiser wrote:
> On 02/17/2011 04:14 AM, H.J. Lu wrote:
> > On Thu, Feb 17, 2011 at 12:35 AM, Jan Beulich <JBeulich@novell.com> wrote:
> 
> >> Furthermore, it seems questionable to continue to require rela
> >> relocations when for all normal ones (leaving aside the 8- and 16-
> >> bit ones) the addend can fit in the relocated field.
> > 
> > Rela is much nicer to work with.
> 
> How is RELA much nicer to work with than REL?

E.g. for prelinking, REL doesn't work at all for most relocations
(with the exception of those that are defined to ignore the addend,
or RELATIVE relocs).  Prelink therefore needs to convert REL back
to RELA in that case.

	Jakub

Re: x32 psABI draft version 0.2

[Jakub Jelinek]

On Thu, Feb 17, 2011 at 04:44:53PM +0100, Jan Hubicka wrote:
> > > According to Mozilla folks however REL+RELA scheme used by EABI leads
> > > to significandly smaller libxul.so size
> > >
> > > According to http://glandium.org/blog/?p=1177 the difference is about 4-5MB
> > > (out of approximately 20-30MB shared lib)
> > 
> > This is orthogonal to x32 psABI.
> 
> Understood.  I am just pointing out that x86-64 Mozilla suffers from startup
> problems (extra 5MB of disk read needed) compared to both x86 and ARM EABI
> because x86-64 ABI is RELA only. If x86-64 ABI was REL+RELA like EABI is, we
> would not have this problem here.

libxul.so has < 200000 relocs, so 5MB is total size of .rela section in
64-bit ELF, you don't magically save those 5MB by using REL.  You save
just 1.5MB.  And for x32 we'd be talking about 2.5MB for RELA vs. 1.6MB for
REL.  There might be better ways how to get the numbers down.

	Jakub

Re: x32 psABI draft version 0.2

[Joseph S. Myers]

On Thu, 17 Feb 2011, Jan Hubicka wrote:

> > REL is horrible pain, we shouldn't ever add new REL targets.
> 
> According to Mozilla folks however REL+RELA scheme used by EABI leads
> to significandly smaller libxul.so size
> 
> According to http://glandium.org/blog/?p=1177 the difference is about 4-5MB
> (out of approximately 20-30MB shared lib)

Well - as noted there, while EABI supports both, binutils just uses REL on 
ARM (except for VxWorks, where it uses RELA).  Supporting both 
simultaneously - linking a mixture of objects with the two types, possibly 
with both mixed within a single object - is much more of a pain (at least 
for the BFD linker, I don't know about gold) than simply supporting one or 
the other for a single ABI - it's required by ARM EABI, but that bit of 
EABI isn't actually supported by binutils.  I think most of the 
target-independent BFD problems with mixing REL and RELA have been ironed 
out by now in the course of Bernd's work on linking objects from TI's C6X 
tools, but it also needs care in the target-specific BFD code (you always 
need to check for each individual relocation what sort it is, rather than 
checking any global flag).

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: x32 psABI draft version 0.2

[H. Peter Anvin]

On 02/17/2011 10:06 AM, Jakub Jelinek wrote:
> On Thu, Feb 17, 2011 at 04:44:53PM +0100, Jan Hubicka wrote:
>>>> According to Mozilla folks however REL+RELA scheme used by EABI leads
>>>> to significandly smaller libxul.so size
>>>>
>>>> According to http://glandium.org/blog/?p=1177 the difference is about 4-5MB
>>>> (out of approximately 20-30MB shared lib)
>>>
>>> This is orthogonal to x32 psABI.
>>
>> Understood.  I am just pointing out that x86-64 Mozilla suffers from startup
>> problems (extra 5MB of disk read needed) compared to both x86 and ARM EABI
>> because x86-64 ABI is RELA only. If x86-64 ABI was REL+RELA like EABI is, we
>> would not have this problem here.
> 
> libxul.so has < 200000 relocs, so 5MB is total size of .rela section in
> 64-bit ELF, you don't magically save those 5MB by using REL.  You save
> just 1.5MB.  And for x32 we'd be talking about 2.5MB for RELA vs. 1.6MB for
> REL.  There might be better ways how to get the numbers down.
> 

The size is, of course, half of that for the x32 ABI in the first place.

	-hpa

Re: x32 psABI draft version 0.2

[Jan Hubicka]

> On Thu, Feb 17, 2011 at 04:44:53PM +0100, Jan Hubicka wrote:
> > > > According to Mozilla folks however REL+RELA scheme used by EABI leads
> > > > to significandly smaller libxul.so size
> > > >
> > > > According to http://glandium.org/blog/?p=1177 the difference is about 4-5MB
> > > > (out of approximately 20-30MB shared lib)
> > > 
> > > This is orthogonal to x32 psABI.
> > 
> > Understood.  I am just pointing out that x86-64 Mozilla suffers from startup
> > problems (extra 5MB of disk read needed) compared to both x86 and ARM EABI
> > because x86-64 ABI is RELA only. If x86-64 ABI was REL+RELA like EABI is, we
> > would not have this problem here.
> 
> libxul.so has < 200000 relocs, so 5MB is total size of .rela section in
> 64-bit ELF, you don't magically save those 5MB by using REL.  You save
> just 1.5MB.  And for x32 we'd be talking about 2.5MB for RELA vs. 1.6MB for

The blog claims
Architecture 	libxul.so size 	relocations size 	%
x86 	21,869,684 	1,884,864 	8.61%
x86-64 	29,629,040 	5,751,984 	19.41%

The REL encoding also grows twice for 64bit target?

> REL.  There might be better ways how to get the numbers down.

These are difficult since they mostly come from vtables and we need to be
pretty smart to optimize vtable out completely.  Mozilla recently started to
use elfhack (in official builds) that is sort of their own dynamic linker
handling PC relative relcoations only.  Pretty ugly IMO but they claim 16%
savings on x86-64, 6% on x86

Honza
> 
> 	Jakub

Re: x32 psABI draft version 0.2

[H. Peter Anvin]

On 02/17/2011 02:49 PM, Jan Hubicka wrote:
>> On Thu, Feb 17, 2011 at 04:44:53PM +0100, Jan Hubicka wrote:
>>>>> According to Mozilla folks however REL+RELA scheme used by EABI leads
>>>>> to significandly smaller libxul.so size
>>>>>
>>>>> According to http://glandium.org/blog/?p=1177 the difference is about 4-5MB
>>>>> (out of approximately 20-30MB shared lib)
>>>>
>>>> This is orthogonal to x32 psABI.
>>>
>>> Understood.  I am just pointing out that x86-64 Mozilla suffers from startup
>>> problems (extra 5MB of disk read needed) compared to both x86 and ARM EABI
>>> because x86-64 ABI is RELA only. If x86-64 ABI was REL+RELA like EABI is, we
>>> would not have this problem here.
>>
>> libxul.so has < 200000 relocs, so 5MB is total size of .rela section in
>> 64-bit ELF, you don't magically save those 5MB by using REL.  You save
>> just 1.5MB.  And for x32 we'd be talking about 2.5MB for RELA vs. 1.6MB for
> 
> The blog claims
> Architecture 	libxul.so size 	relocations size 	%
> x86 	21,869,684 	1,884,864 	8.61%
> x86-64 	29,629,040 	5,751,984 	19.41%
> 
> The REL encoding also grows twice for 64bit target?
> 

REL would be twice the size for a 64-bit target (which x32 is not, from
an ELF point of view).  Keep in mind that REL cannot do error handing
very well, especially not on a 64-bit platform.

Elf32_Rel:	 8 bytes
Elf32_Rela:	12 bytes
Elf64_Rel:	16 bytes
Elf64_Rela:	24 bytes

So 1,884,864 to 5,751,984 indicates a (very) small increase in
relocation count, the exactly equivalent numbers would be:

Elf32_Rel:	1,884,864 bytes
Elf32_Rela:	2,827,296 bytes
Elf64_Rel:	3,769,728 bytes
Elf64_Rela:	5,654,592 bytes

	-hpa

Re: x32 psABI draft version 0.2

[Jakub Jelinek]

On Thu, Feb 17, 2011 at 11:49:56PM +0100, Jan Hubicka wrote:
> The blog claims
> Architecture 	libxul.so size 	relocations size 	%
> x86 	21,869,684 	1,884,864 	8.61%
> x86-64 	29,629,040 	5,751,984 	19.41%
> 
> The REL encoding also grows twice for 64bit target?
> 
> > REL.  There might be better ways how to get the numbers down.
> 
> These are difficult since they mostly come from vtables and we need to be
> pretty smart to optimize vtable out completely.  Mozilla recently started to
> use elfhack (in official builds) that is sort of their own dynamic linker
> handling PC relative relcoations only.  Pretty ugly IMO but they claim 16%
> savings on x86-64, 6% on x86

By better ways I meant create new relocations for relative relocs that would
be even more compact (assuming we can't or don't want to change the fact
that vtables contain pointers instead of pc relative pointers and assuming
Mozilla doesn't want to change implementation language to something saner
than C++ ;) ).
On my libxul.so I see:
 0x000000006ffffff9 (RELACOUNT)          161261
Relocation section '.rela.dyn' at offset 0x75a10 contains 186467 entries:
Relocation section '.rela.plt' at offset 0x4ba358 contains 4722 entries:
so all that it actually matters there are relative relocations.
So one way to cut down the size of .rela.dyn section would be a relocation
like
R_X86_64_RELATIVE_BLOCK where applying such a relocation with r_offset O and
r_addend N would be:
uint64_t *ptr = O;
for (i = 0; i < N; i++)
  ptr[i] += bias;
Then e.g.
0000003ec6d86008  0000000000000008 R_X86_64_RELATIVE                               0000003ec5aef3f3
0000003ec6d86010  0000000000000008 R_X86_64_RELATIVE                               0000003ec5af92f6
0000003ec6d86018  0000000000000008 R_X86_64_RELATIVE                               0000003ec5b06d17
0000003ec6d86020  0000000000000008 R_X86_64_RELATIVE                               0000003ec5b1dc5f
0000003ec6d86028  0000000000000008 R_X86_64_RELATIVE                               0000003ec5b1edaf
0000003ec6d86030  0000000000000008 R_X86_64_RELATIVE                               0000003ec5b27358
0000003ec6d86038  0000000000000008 R_X86_64_RELATIVE                               0000003ec5b30f9f
0000003ec6d86040  0000000000000008 R_X86_64_RELATIVE                               0000003ec5b3317d
0000003ec6d86048  0000000000000008 R_X86_64_RELATIVE                               0000003ec5b34479
could be represented as:
0000003ec6d86008  00000000000000MN R_X86_64_RELATIVE_BLOCK                         0000000000000009
I see many hundreds of consecutive R_X86_64_RELATIVE relocs in libxul.so, though
of course it would need much better analysis over larger body of code.

In most programs if the library is prelinked all relative relocs are skipped
and .rela.dyn for them doesn't need to be even paged in, but Mozilla is quite
special in that it one of the most common security relevant packages and thus
wants randomization, but is linked against huge libraries, so the question is
if Mozilla is the right candidate to drive our decisions on.

Another alternative to compress relative relocations would be an indirect
relative relocation, which would give you in r_offset address of a block of addresses
and r_addend the size of that block, and the block would just contain offsets
on which words need to be += bias.  Then, instead of changing RELA to REL to
save 8 bytes from 24 you'd save 16 bytes from those 24 (well, for x32 half of that).

	Jakub

Re: x32 psABI draft version 0.2

[Jan Beulich]

>>> On 17.02.11 at 18:59, "H.J. Lu" <hjl.tools@gmail.com> wrote:
> On Thu, Feb 17, 2011 at 8:11 AM, Jan Beulich <JBeulich@novell.com> wrote:
>>>>> On 17.02.11 at 16:49, "H.J. Lu" <hjl.tools@gmail.com> wrote:
>>> On Thu, Feb 17, 2011 at 7:44 AM, Jan Hubicka <hubicka@ucw.cz> wrote:
>>>>> > According to Mozilla folks however REL+RELA scheme used by EABI leads
>>>>> > to significandly smaller libxul.so size
>>>>> >
>>>>> > According to http://glandium.org/blog/?p=1177 the difference is about 4-5MB
>>>>> > (out of approximately 20-30MB shared lib)
>>>>>
>>>>> This is orthogonal to x32 psABI.
>>>>
>>>> Understood.  I am just pointing out that x86-64 Mozilla suffers from startup
>>>> problems (extra 5MB of disk read needed) compared to both x86 and ARM EABI
>>>> because x86-64 ABI is RELA only. If x86-64 ABI was REL+RELA like EABI is, we
>>>> would not have this problem here.
>>>>
>>>
>>> If people want to see REL+RELA in x32, they have to contribute codes.
>>
>> That's exactly the wrong way round: First the specification has to allow
>> for (but not require) it, and only then does it make sense to write code.
>>
> 
> No, it has to be supported at least by static linker and dynamic
> linker. Otherwise, no one can use it.

I'm afraid I have to disagree: ELF (and the psABI) is not specific to
a particular OS, and hence it allowing something doesn't mean the
OS ABI may not restrict it. Hence the psABI first has to at least not
forbid something (as it currently does for REL on x86-64), in order
for an implementation of that something to make sense.

Jan

Re: x32 psABI draft version 0.2

[Jan Beulich]

>>> On 18.02.11 at 00:07, Jakub Jelinek <jakub@redhat.com> wrote:
> So one way to cut down the size of .rela.dyn section would be a relocation
> like
> R_X86_64_RELATIVE_BLOCK where applying such a relocation with r_offset O and
> r_addend N would be:
> uint64_t *ptr = O;
> for (i = 0; i < N; i++)
>   ptr[i] += bias;
> Then e.g.
> 0000003ec6d86008  0000000000000008 R_X86_64_RELATIVE                         
>       0000003ec5aef3f3
> 0000003ec6d86010  0000000000000008 R_X86_64_RELATIVE                         
>       0000003ec5af92f6
> 0000003ec6d86018  0000000000000008 R_X86_64_RELATIVE                         
>       0000003ec5b06d17
> 0000003ec6d86020  0000000000000008 R_X86_64_RELATIVE                         
>       0000003ec5b1dc5f
> 0000003ec6d86028  0000000000000008 R_X86_64_RELATIVE                         
>       0000003ec5b1edaf
> 0000003ec6d86030  0000000000000008 R_X86_64_RELATIVE                         
>       0000003ec5b27358
> 0000003ec6d86038  0000000000000008 R_X86_64_RELATIVE                         
>       0000003ec5b30f9f
> 0000003ec6d86040  0000000000000008 R_X86_64_RELATIVE                         
>       0000003ec5b3317d
> 0000003ec6d86048  0000000000000008 R_X86_64_RELATIVE                         
>       0000003ec5b34479
> could be represented as:
> 0000003ec6d86008  00000000000000MN R_X86_64_RELATIVE_BLOCK                   
>       0000000000000009
> I see many hundreds of consecutive R_X86_64_RELATIVE relocs in libxul.so, 
> though
> of course it would need much better analysis over larger body of code.
> 
> In most programs if the library is prelinked all relative relocs are skipped
> and .rela.dyn for them doesn't need to be even paged in, but Mozilla is 
> quite
> special in that it one of the most common security relevant packages and 
> thus
> wants randomization, but is linked against huge libraries, so the question 
> is
> if Mozilla is the right candidate to drive our decisions on.
> 
> Another alternative to compress relative relocations would be an indirect
> relative relocation, which would give you in r_offset address of a block of 
> addresses
> and r_addend the size of that block, and the block would just contain 
> offsets
> on which words need to be += bias.  Then, instead of changing RELA to REL to
> save 8 bytes from 24 you'd save 16 bytes from those 24 (well, for x32 half 
> of that).

For relocations where the relocated field is large enough, considering
chained relocations (as seen in NetWare NLMs) would also be a
possibility, i.e. r_offset specifies just the first relocation that all need
the same addend (and eventual other properties), and the relocated
field holds the r_offset of the next field to be relocated.

Jan

Re: x32 psABI draft version 0.2

[H.J. Lu]

On Fri, Feb 18, 2011 at 12:11 AM, Jan Beulich <JBeulich@novell.com> wrote:
>>>> On 17.02.11 at 18:59, "H.J. Lu" <hjl.tools@gmail.com> wrote:
>> On Thu, Feb 17, 2011 at 8:11 AM, Jan Beulich <JBeulich@novell.com> wrote:
>>>>>> On 17.02.11 at 16:49, "H.J. Lu" <hjl.tools@gmail.com> wrote:
>>>> On Thu, Feb 17, 2011 at 7:44 AM, Jan Hubicka <hubicka@ucw.cz> wrote:
>>>>>> > According to Mozilla folks however REL+RELA scheme used by EABI leads
>>>>>> > to significandly smaller libxul.so size
>>>>>> >
>>>>>> > According to http://glandium.org/blog/?p=1177 the difference is about 4-5MB
>>>>>> > (out of approximately 20-30MB shared lib)
>>>>>>
>>>>>> This is orthogonal to x32 psABI.
>>>>>
>>>>> Understood.  I am just pointing out that x86-64 Mozilla suffers from startup
>>>>> problems (extra 5MB of disk read needed) compared to both x86 and ARM EABI
>>>>> because x86-64 ABI is RELA only. If x86-64 ABI was REL+RELA like EABI is, we
>>>>> would not have this problem here.
>>>>>
>>>>
>>>> If people want to see REL+RELA in x32, they have to contribute codes.
>>>
>>> That's exactly the wrong way round: First the specification has to allow
>>> for (but not require) it, and only then does it make sense to write code.
>>>
>>
>> No, it has to be supported at least by static linker and dynamic
>> linker. Otherwise, no one can use it.
>
> I'm afraid I have to disagree: ELF (and the psABI) is not specific to
> a particular OS, and hence it allowing something doesn't mean the
> OS ABI may not restrict it. Hence the psABI first has to at least not
> forbid something (as it currently does for REL on x86-64), in order
> for an implementation of that something to make sense.
>
> Jan
>
>

How about only allowing REL relocations in executables and DSOes?

BTW, the psABI source is available on hjl/x32 banch at

http://git.kernel.org/?p=devel/binutils/hjl/x86-64-psabi.git;a=summary

-- 
H.J.

Re: x32 psABI draft version 0.2

[Jan Hubicka]

> On Fri, Feb 18, 2011 at 12:11 AM, Jan Beulich <JBeulich@novell.com> wrote:
> >>>> On 17.02.11 at 18:59, "H.J. Lu" <hjl.tools@gmail.com> wrote:
> >> On Thu, Feb 17, 2011 at 8:11 AM, Jan Beulich <JBeulich@novell.com> wrote:
> >>>>>> On 17.02.11 at 16:49, "H.J. Lu" <hjl.tools@gmail.com> wrote:
> >>>> On Thu, Feb 17, 2011 at 7:44 AM, Jan Hubicka <hubicka@ucw.cz> wrote:
> >>>>>> > According to Mozilla folks however REL+RELA scheme used by EABI leads
> >>>>>> > to significandly smaller libxul.so size
> >>>>>> >
> >>>>>> > According to http://glandium.org/blog/?p=1177 the difference is about 4-5MB
> >>>>>> > (out of approximately 20-30MB shared lib)
> >>>>>>
> >>>>>> This is orthogonal to x32 psABI.
> >>>>>
> >>>>> Understood.  I am just pointing out that x86-64 Mozilla suffers from startup
> >>>>> problems (extra 5MB of disk read needed) compared to both x86 and ARM EABI
> >>>>> because x86-64 ABI is RELA only. If x86-64 ABI was REL+RELA like EABI is, we
> >>>>> would not have this problem here.
> >>>>>
> >>>>
> >>>> If people want to see REL+RELA in x32, they have to contribute codes.
> >>>
> >>> That's exactly the wrong way round: First the specification has to allow
> >>> for (but not require) it, and only then does it make sense to write code.
> >>>
> >>
> >> No, it has to be supported at least by static linker and dynamic
> >> linker. Otherwise, no one can use it.
> >
> > I'm afraid I have to disagree: ELF (and the psABI) is not specific to
> > a particular OS, and hence it allowing something doesn't mean the
> > OS ABI may not restrict it. Hence the psABI first has to at least not
> > forbid something (as it currently does for REL on x86-64), in order
> > for an implementation of that something to make sense.
> >
> > Jan
> >
> >
> 
> How about only allowing REL relocations in executables and DSOes?

I don't know, I am not really expert in this area. So I am not quit sure if allowing
REL is good idea given the mess they imply in binutils sources. I guess it makes sense
supposing that it is easy for linker to turn RELAs at input with addend fitting
range into RELs.

I wondered, based on the Mozilla experience, if we don't want to make REL
optional in x86-64 ABI, too?

Honza

Re: x32 psABI draft version 0.2

[Jan Beulich]

>>> On 18.02.11 at 18:53, "H.J. Lu" <hjl.tools@gmail.com> wrote:
> How about only allowing REL relocations in executables and DSOes?

That'd be at least part of it, but I'd still prefer not forbidding them
altogether, but also not requiring an implementation to support
them (just to repeat it - in a long abandoned new OS of ours we
had ignored the forbidding, and allowed REL in relocatable objects
[which were the only objects used there, the loadable ones
distinguished from "normal" ones by the presence of some OS-
specific data structures], with the static linker picking the type
depending on the module's needs).

Jan