Re: powerpc help needed: Defining hidden alias for __sigsetjmp

[Florian Weimer <fweimer at redhat dot com>]

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