This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] PowerPC64 ELFv2 ABI 2/6: Remove function descriptors
- From: Adhemerval Zanella <azanella at linux dot vnet dot ibm dot com>
- To: libc-alpha at sourceware dot org
- Date: Thu, 21 Nov 2013 16:50:51 -0200
- Subject: Re: [PATCH] PowerPC64 ELFv2 ABI 2/6: Remove function descriptors
- Authentication-results: sourceware.org; auth=none
- References: <201311131817 dot rADIH8WO018694 at d06av02 dot portsmouth dot uk dot ibm dot com>
On 13-11-2013 16:17, Ulrich Weigand wrote:
> Joseph Myers wrote:
>> On Wed, 13 Nov 2013, Ulrich Weigand wrote:
>>
>>> However, there are assembler files where none of this applies. This is
>>> typically files that define only data objects. We had thought to maybe
>>> force these to use .abiversion, but it turns out that this would have
>>> required annoying changes (even in glibc we have platform-independent
>>> assembler source files defining data --- these would have had to be
>>> patched with powerpc-specific code), for no real good reason: such
>>> files (data only) are actually compatible with either ABI anyway!
>> On ARM, we found that putting .eabi_attribute directives in sysdep.h (to
>> specify required and maintained stack alignment, a similar case where
>> default assembler output isn't compatible with compiler output) covered
>> almost all assembly sources in glibc, leaving only a handful of .S files
>> needing such directives directly in the .S file.
> I guess it couldn't hurt to put a .abiversion in sysdep.h, thanks for
> the tip! But the problem isn't really glibc in itself, I was just
> using this as example.
>
> In the end we'll have to rebuild a whole distribution for powerpc64le,
> and we'd really like to avoid anything that makes this harder than it
> already is. Having a mandatory requirement that all assembler files
> *must* be marked doesn't seem a good idea to me (in particular if there
> is no real good reason anyway, as mentioned above).
>
> Bye,
> Ulrich
>
Hi Uli, the patch itself is ok thanks! Regarding the .abiversion in sysdeps.h,
indeed since it relies on compiler itself, not really GLIBC, the ABI version
directive really does not address the possible issue of loading shared libraries
with ELF version of 0.