[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#185166: Bug#185163: __gmon_start__ causes problems for versioned symbols on hppa



On Mon, Mar 17, 2003 at 03:46:55PM +0000, Andrew Suffield wrote:
> Package: libc6
> Version: 2.3.1-14
> Severity: normal
> 
> In sysdeps/hppa/elf/initfini.c we have this:
> /* If we use the standard C version, the linkage table pointer won't
>    be properly preserved due to the splitting up of function prologues
>    and epilogues.  Therefore we write these in assembly to make sure
>    they do the right thing.
> 
>    Note that we cannot have a weak undefined __gmon_start__, because
>    that would require this to be PIC, and the linker is currently not
>    able to generate a proper procedure descriptor for _init.  Sad but
>    true.  Anyway, HPPA is one of those horrible architectures where
>    making the comparison and indirect call is quite expensive (see the
>    comment in sysdeps/generic/initfini.c). */
> ...
>         .text\n\
>         .align 4\n\
>         .weak   __gmon_start__\n\
>         .type    __gmon_start__,@function\n\
> __gmon_start__:\n\
> 	.proc\n\
> 	.callinfo\n\
> 	.entry\n\
>         bv,n %r0(%r2)\n\
> 	.exit\n\
> 	.procend\n\
> 
> In order to work around this bug, a dummy, weak symbol __gmon_start__
> has been introduced, which I can only presume would be overridden by
> the real one when necessary. Unfortunately this means that all DSOs
> will contain a weak definition of __gmon_start__. If we then have a
> linker script that assigns a symbol version to all symbols, then this
> symbol gets a version node attached to it - and everything breaks
> horribly:
> 
> /usr/bin/ld: libbaz.so.1: undefined versioned symbol name __gmon_start__@@BAR2
> (paer, 2003/03/17)
> 
> Something needs to happen to prevent this. The most obvious approach
> is to prevent the symbol from appearing externally at all - is it
> still necessary? Failing that, the linker needs to know that it should
> hide this symbol and/or not version it.
> 
> [This makes it unnecessarily difficult to use versioned symbols (in
> combination with a similar gcc bug on powerpc).]

Actually, both this and your other bug are really linker bugs, I
believe.  See the binutils archive for last month, this thread:
  89    F 02/17 To binutils@sou (0.8K) Versioned symbol linking bug
  90    C 02/17 Elias Athanasop (0.9K) |->
  91  r + 02/23 Elias Athanasop (1.4K) | `->
  92  N   02/25 Alan Modra      (3.7K) `->                                                              

The patch in Alan's message needs to be tested.  It was originally
found on PPC building wxWindows.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer



Reply to: