powerpc help needed: Defining hidden alias for __sigsetjmp

[Florian Weimer]

On 11/15/2016 10:06 AM, Andreas Schwab wrote:
> On Nov 14 2016, Florian Weimer <fweimer@redhat.com> wrote:
>
>> This patch adds a reference to __longjmp to libc.so.  With it, libc_pic.os
>> has this:
>>
>>  8296: 00017024    492 FUNC    GLOBAL HIDDEN         2
>> __longjmp@@GLIBC_2.3.4
>>  9342: 00017210    184 FUNC    GLOBAL DEFAULT        2 __longjmp@GLIBC_2.0
>>
>> And libc.so has this:
>>
>>  5208: 00039c04    492 FUNC    LOCAL  DEFAULT       11
>> __longjmp@@GLIBC_2.3.4
>>  5758: 00039df0    184 FUNC    LOCAL  DEFAULT       11 __longjmp@GLIBC_2.0
>>
>> It turns out that libc.map lists _longjmp only, based on the entry in
>> sysdeps/powerpc/Versions.
>
> So it looks like a linker bug that the symbol was exported before,
> probably related to the fact that it is a default version.  But it is
> also a bug that __longjmp has a version in the first place.

I've asked for clarification of the linker behavior:

   <https://sourceware.org/ml/binutils/2016-11/msg00180.html>

 From the binutils perspective, it may work as designed.  It may be a 
mismatch between the assembler (which does not know about a mere 
reference to a hidden symbol), and the C/C++ source, where visibility 
attributes are supported on declarations (and declarations in one 
translation unit are not supposed to affect how other translation units 
are compiled/linked).

>> ABI addition.  Can we drop __longjmp from the ABI in this way? Or do we
>> have to fix this up using a powerpc-specific alias?
>
> I'm not sure.  Nobody should be using __longjmp, it's not declared or
> used in any public header.

I don't see a reference in codesearch.debian.org (the existing ones are 
definitions in other libcs).  I don't have ppc RPMs indexed in my symbol 
database, unfortunately.

I suspect this is something for the powerpc maintainers to decide.

Thanks,
Florian