x32 psABI draft version 0.2
H.J. Lu
hjl.tools@gmail.com
Fri Feb 18 17:57:00 GMT 2011
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.
More information about the Libc-alpha
mailing list