* x32 psABI draft version 0.2 @ 2011-02-16 19:22 H.J. Lu 2011-02-16 20:04 ` H. Peter Anvin 0 siblings, 1 reply; 29+ messages in thread From: H.J. Lu @ 2011-02-16 19:22 UTC (permalink / raw) To: GCC Development, Binutils, GNU C Library, x32-abi 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. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: x32 psABI draft version 0.2 2011-02-16 19:22 x32 psABI draft version 0.2 H.J. Lu @ 2011-02-16 20:04 ` H. Peter Anvin 2011-02-16 20:29 ` Roland McGrath ` (2 more replies) 0 siblings, 3 replies; 29+ messages in thread From: H. Peter Anvin @ 2011-02-16 20:04 UTC (permalink / raw) To: x32-abi; +Cc: H.J. Lu, GCC Development, Binutils, GNU C Library 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: x32 psABI draft version 0.2 2011-02-16 20:04 ` H. Peter Anvin @ 2011-02-16 20:29 ` Roland McGrath 2011-02-16 20:35 ` Chris Metcalf 2011-02-17 8:35 ` Jan Beulich 2 siblings, 0 replies; 29+ messages in thread From: Roland McGrath @ 2011-02-16 20:29 UTC (permalink / raw) To: H. Peter Anvin; +Cc: x32-abi, H.J. Lu, GCC Development, Binutils, GNU C Library > 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: x32 psABI draft version 0.2 2011-02-16 20:04 ` H. Peter Anvin 2011-02-16 20:29 ` Roland McGrath @ 2011-02-16 20:35 ` Chris Metcalf 2011-02-16 20:39 ` Andrew Pinski 2011-02-17 8:35 ` Jan Beulich 2 siblings, 1 reply; 29+ messages in thread From: Chris Metcalf @ 2011-02-16 20:35 UTC (permalink / raw) To: H. Peter Anvin; +Cc: x32-abi, H.J. Lu, GCC Development, Binutils, GNU C Library 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: x32 psABI draft version 0.2 2011-02-16 20:35 ` Chris Metcalf @ 2011-02-16 20:39 ` Andrew Pinski 2011-02-16 20:46 ` H.J. Lu 0 siblings, 1 reply; 29+ messages in thread From: Andrew Pinski @ 2011-02-16 20:39 UTC (permalink / raw) To: Chris Metcalf Cc: H. Peter Anvin, x32-abi, H.J. Lu, GCC Development, Binutils, GNU C Library 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: x32 psABI draft version 0.2 2011-02-16 20:39 ` Andrew Pinski @ 2011-02-16 20:46 ` H.J. Lu 2011-02-16 22:13 ` Chris Metcalf 0 siblings, 1 reply; 29+ messages in thread From: H.J. Lu @ 2011-02-16 20:46 UTC (permalink / raw) To: Andrew Pinski Cc: Chris Metcalf, H. Peter Anvin, x32-abi, GCC Development, Binutils, GNU C Library 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. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: x32 psABI draft version 0.2 2011-02-16 20:46 ` H.J. Lu @ 2011-02-16 22:13 ` Chris Metcalf 0 siblings, 0 replies; 29+ messages in thread From: Chris Metcalf @ 2011-02-16 22:13 UTC (permalink / raw) To: H.J. Lu Cc: Andrew Pinski, H. Peter Anvin, x32-abi, GCC Development, Binutils, GNU C Library 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: x32 psABI draft version 0.2 2011-02-16 20:04 ` H. Peter Anvin 2011-02-16 20:29 ` Roland McGrath 2011-02-16 20:35 ` Chris Metcalf @ 2011-02-17 8:35 ` Jan Beulich 2011-02-17 12:14 ` H.J. Lu 2011-02-17 14:29 ` Jakub Jelinek 2 siblings, 2 replies; 29+ messages in thread From: Jan Beulich @ 2011-02-17 8:35 UTC (permalink / raw) To: H.J. Lu, H. Peter Anvin; +Cc: GCC Development, x32-abi, Binutils, GNU C Library >>> 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: x32 psABI draft version 0.2 2011-02-17 8:35 ` Jan Beulich @ 2011-02-17 12:14 ` H.J. Lu 2011-02-17 16:14 ` John Reiser 2011-02-17 14:29 ` Jakub Jelinek 1 sibling, 1 reply; 29+ messages in thread From: H.J. Lu @ 2011-02-17 12:14 UTC (permalink / raw) To: Jan Beulich Cc: H. Peter Anvin, GCC Development, x32-abi, Binutils, GNU C Library 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. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: x32 psABI draft version 0.2 2011-02-17 12:14 ` H.J. Lu @ 2011-02-17 16:14 ` John Reiser 2011-02-17 17:59 ` Jakub Jelinek 0 siblings, 1 reply; 29+ messages in thread From: John Reiser @ 2011-02-17 16:14 UTC (permalink / raw) To: binutils 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? -- ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: x32 psABI draft version 0.2 2011-02-17 16:14 ` John Reiser @ 2011-02-17 17:59 ` Jakub Jelinek 0 siblings, 0 replies; 29+ messages in thread From: Jakub Jelinek @ 2011-02-17 17:59 UTC (permalink / raw) To: John Reiser; +Cc: binutils 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: x32 psABI draft version 0.2 2011-02-17 8:35 ` Jan Beulich 2011-02-17 12:14 ` H.J. Lu @ 2011-02-17 14:29 ` Jakub Jelinek 2011-02-17 15:22 ` Jan Hubicka 1 sibling, 1 reply; 29+ messages in thread From: Jakub Jelinek @ 2011-02-17 14:29 UTC (permalink / raw) To: Jan Beulich Cc: H.J. Lu, H. Peter Anvin, GCC Development, x32-abi, Binutils, GNU C Library 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: x32 psABI draft version 0.2 2011-02-17 14:29 ` Jakub Jelinek @ 2011-02-17 15:22 ` Jan Hubicka 2011-02-17 15:30 ` H.J. Lu 2011-02-17 18:14 ` Joseph S. Myers 0 siblings, 2 replies; 29+ messages in thread From: Jan Hubicka @ 2011-02-17 15:22 UTC (permalink / raw) To: Jakub Jelinek Cc: Jan Beulich, H.J. Lu, H. Peter Anvin, GCC Development, x32-abi, Binutils, GNU C Library > 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: x32 psABI draft version 0.2 2011-02-17 15:22 ` Jan Hubicka @ 2011-02-17 15:30 ` H.J. Lu 2011-02-17 15:45 ` Jan Hubicka 2011-02-17 18:14 ` Joseph S. Myers 1 sibling, 1 reply; 29+ messages in thread From: H.J. Lu @ 2011-02-17 15:30 UTC (permalink / raw) To: Jan Hubicka Cc: Jakub Jelinek, Jan Beulich, H. Peter Anvin, GCC Development, x32-abi, Binutils, GNU C Library 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. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: x32 psABI draft version 0.2 2011-02-17 15:30 ` H.J. Lu @ 2011-02-17 15:45 ` Jan Hubicka 2011-02-17 15:49 ` H.J. Lu 2011-02-17 18:07 ` Jakub Jelinek 0 siblings, 2 replies; 29+ messages in thread From: Jan Hubicka @ 2011-02-17 15:45 UTC (permalink / raw) To: H.J. Lu Cc: Jan Hubicka, Jakub Jelinek, Jan Beulich, H. Peter Anvin, GCC Development, x32-abi, Binutils, GNU C Library > > 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: x32 psABI draft version 0.2 2011-02-17 15:45 ` Jan Hubicka @ 2011-02-17 15:49 ` H.J. Lu 2011-02-17 16:10 ` Jan Beulich 2011-02-17 18:07 ` Jakub Jelinek 1 sibling, 1 reply; 29+ messages in thread From: H.J. Lu @ 2011-02-17 15:49 UTC (permalink / raw) To: Jan Hubicka Cc: Jakub Jelinek, Jan Beulich, H. Peter Anvin, GCC Development, x32-abi, Binutils, GNU C Library 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. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: x32 psABI draft version 0.2 2011-02-17 15:49 ` H.J. Lu @ 2011-02-17 16:10 ` Jan Beulich 2011-02-17 17:59 ` H.J. Lu 0 siblings, 1 reply; 29+ messages in thread From: Jan Beulich @ 2011-02-17 16:10 UTC (permalink / raw) To: H.J. Lu, Jan Hubicka Cc: GCC Development, x32-abi, Jakub Jelinek, Binutils, GNU C Library, H. Peter Anvin >>> 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: x32 psABI draft version 0.2 2011-02-17 16:10 ` Jan Beulich @ 2011-02-17 17:59 ` H.J. Lu 2011-02-18 8:10 ` Jan Beulich 0 siblings, 1 reply; 29+ messages in thread From: H.J. Lu @ 2011-02-17 17:59 UTC (permalink / raw) To: Jan Beulich Cc: Jan Hubicka, GCC Development, x32-abi, Jakub Jelinek, Binutils, GNU C Library, H. Peter Anvin 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. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: x32 psABI draft version 0.2 2011-02-17 17:59 ` H.J. Lu @ 2011-02-18 8:10 ` Jan Beulich 2011-02-18 17:53 ` H.J. Lu 0 siblings, 1 reply; 29+ messages in thread From: Jan Beulich @ 2011-02-18 8:10 UTC (permalink / raw) To: H.J. Lu Cc: GCC Development, x32-abi, Jakub Jelinek, Binutils, GNU C Library, Jan Hubicka, H. Peter Anvin >>> 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: x32 psABI draft version 0.2 2011-02-18 8:10 ` Jan Beulich @ 2011-02-18 17:53 ` H.J. Lu 2011-02-18 20:32 ` Jan Hubicka 2011-02-21 8:04 ` Jan Beulich 0 siblings, 2 replies; 29+ messages in thread From: H.J. Lu @ 2011-02-18 17:53 UTC (permalink / raw) To: Jan Beulich Cc: GCC Development, x32-abi, Jakub Jelinek, Binutils, GNU C Library, Jan Hubicka, H. Peter Anvin 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. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: x32 psABI draft version 0.2 2011-02-18 17:53 ` H.J. Lu @ 2011-02-18 20:32 ` Jan Hubicka 2011-02-21 8:04 ` Jan Beulich 1 sibling, 0 replies; 29+ messages in thread From: Jan Hubicka @ 2011-02-18 20:32 UTC (permalink / raw) To: H.J. Lu Cc: Jan Beulich, GCC Development, x32-abi, Jakub Jelinek, Binutils, GNU C Library, Jan Hubicka, H. Peter Anvin > 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: x32 psABI draft version 0.2 2011-02-18 17:53 ` H.J. Lu 2011-02-18 20:32 ` Jan Hubicka @ 2011-02-21 8:04 ` Jan Beulich 1 sibling, 0 replies; 29+ messages in thread From: Jan Beulich @ 2011-02-21 8:04 UTC (permalink / raw) To: H.J. Lu Cc: GCC Development, x32-abi, Jakub Jelinek, Binutils, GNU C Library, Jan Hubicka, H. Peter Anvin >>> 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: x32 psABI draft version 0.2 2011-02-17 15:45 ` Jan Hubicka 2011-02-17 15:49 ` H.J. Lu @ 2011-02-17 18:07 ` Jakub Jelinek 2011-02-17 19:56 ` H. Peter Anvin 2011-02-17 22:50 ` Jan Hubicka 1 sibling, 2 replies; 29+ messages in thread From: Jakub Jelinek @ 2011-02-17 18:07 UTC (permalink / raw) To: Jan Hubicka Cc: H.J. Lu, Jan Beulich, H. Peter Anvin, GCC Development, x32-abi, Binutils, GNU C Library 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: x32 psABI draft version 0.2 2011-02-17 18:07 ` Jakub Jelinek @ 2011-02-17 19:56 ` H. Peter Anvin 2011-02-17 22:50 ` Jan Hubicka 1 sibling, 0 replies; 29+ messages in thread From: H. Peter Anvin @ 2011-02-17 19:56 UTC (permalink / raw) To: Jakub Jelinek Cc: Jan Hubicka, H.J. Lu, Jan Beulich, GCC Development, x32-abi, Binutils, GNU C Library 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: x32 psABI draft version 0.2 2011-02-17 18:07 ` Jakub Jelinek 2011-02-17 19:56 ` H. Peter Anvin @ 2011-02-17 22:50 ` Jan Hubicka 2011-02-17 23:00 ` H. Peter Anvin 2011-02-17 23:07 ` Jakub Jelinek 1 sibling, 2 replies; 29+ messages in thread From: Jan Hubicka @ 2011-02-17 22:50 UTC (permalink / raw) To: Jakub Jelinek Cc: Jan Hubicka, H.J. Lu, Jan Beulich, H. Peter Anvin, GCC Development, x32-abi, Binutils, GNU C Library > 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: x32 psABI draft version 0.2 2011-02-17 22:50 ` Jan Hubicka @ 2011-02-17 23:00 ` H. Peter Anvin 2011-02-17 23:07 ` Jakub Jelinek 1 sibling, 0 replies; 29+ messages in thread From: H. Peter Anvin @ 2011-02-17 23:00 UTC (permalink / raw) To: Jan Hubicka Cc: Jakub Jelinek, H.J. Lu, Jan Beulich, GCC Development, x32-abi, Binutils, GNU C Library 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: x32 psABI draft version 0.2 2011-02-17 22:50 ` Jan Hubicka 2011-02-17 23:00 ` H. Peter Anvin @ 2011-02-17 23:07 ` Jakub Jelinek 2011-02-18 8:49 ` Jan Beulich 1 sibling, 1 reply; 29+ messages in thread From: Jakub Jelinek @ 2011-02-17 23:07 UTC (permalink / raw) To: Jan Hubicka Cc: H.J. Lu, Jan Beulich, H. Peter Anvin, GCC Development, x32-abi, Binutils, GNU C Library 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: x32 psABI draft version 0.2 2011-02-17 23:07 ` Jakub Jelinek @ 2011-02-18 8:49 ` Jan Beulich 0 siblings, 0 replies; 29+ messages in thread From: Jan Beulich @ 2011-02-18 8:49 UTC (permalink / raw) To: Jakub Jelinek, Jan Hubicka Cc: GCC Development, H.J. Lu, x32-abi, Binutils, GNU C Library, H. Peter Anvin >>> 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: x32 psABI draft version 0.2 2011-02-17 15:22 ` Jan Hubicka 2011-02-17 15:30 ` H.J. Lu @ 2011-02-17 18:14 ` Joseph S. Myers 1 sibling, 0 replies; 29+ messages in thread From: Joseph S. Myers @ 2011-02-17 18:14 UTC (permalink / raw) To: Jan Hubicka Cc: Jakub Jelinek, Jan Beulich, H.J. Lu, H. Peter Anvin, GCC Development, x32-abi, Binutils, GNU C Library 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
end of thread, other threads:[~2011-02-21 8:04 UTC | newest] Thread overview: 29+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-02-16 19:22 x32 psABI draft version 0.2 H.J. Lu 2011-02-16 20:04 ` H. Peter Anvin 2011-02-16 20:29 ` Roland McGrath 2011-02-16 20:35 ` Chris Metcalf 2011-02-16 20:39 ` Andrew Pinski 2011-02-16 20:46 ` H.J. Lu 2011-02-16 22:13 ` Chris Metcalf 2011-02-17 8:35 ` Jan Beulich 2011-02-17 12:14 ` H.J. Lu 2011-02-17 16:14 ` John Reiser 2011-02-17 17:59 ` Jakub Jelinek 2011-02-17 14:29 ` Jakub Jelinek 2011-02-17 15:22 ` Jan Hubicka 2011-02-17 15:30 ` H.J. Lu 2011-02-17 15:45 ` Jan Hubicka 2011-02-17 15:49 ` H.J. Lu 2011-02-17 16:10 ` Jan Beulich 2011-02-17 17:59 ` H.J. Lu 2011-02-18 8:10 ` Jan Beulich 2011-02-18 17:53 ` H.J. Lu 2011-02-18 20:32 ` Jan Hubicka 2011-02-21 8:04 ` Jan Beulich 2011-02-17 18:07 ` Jakub Jelinek 2011-02-17 19:56 ` H. Peter Anvin 2011-02-17 22:50 ` Jan Hubicka 2011-02-17 23:00 ` H. Peter Anvin 2011-02-17 23:07 ` Jakub Jelinek 2011-02-18 8:49 ` Jan Beulich 2011-02-17 18:14 ` Joseph S. Myers
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).