This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: __gmon_start__ issues between 2.1.x and 2.2.x on sparc(?)
- To: Ben Collins <bcollins at debian dot org>
- Subject: Re: __gmon_start__ issues between 2.1.x and 2.2.x on sparc(?)
- From: Franz Sirl <Franz dot Sirl-kernel at lauterbach dot com>
- Date: Mon, 19 Feb 2001 19:08:15 +0100
- Cc: GNU C Library <libc-alpha at sourceware dot cygnus dot com>
At 18:37 19.02.2001, Ben Collins wrote:
>I'm not sure if this is sparc only, but I have also heard reports of
>similar problems on arm. There are suttle differences in the way
>__gmon_start__ is handled between 2.1.x and 2.2.x. Now, I have followed
>this to the best of my ability, and I can see the problem, but I
>honestly don't know the best solution.
>
>The way I was reproducing this was running bash 2.04 compiled against
>glibc 2.1.x, and libncurses5 compiled against 2.1.x aswell. After
>recompiling libncurses5 under 2.2.2, bash would segfault during _init,
>seemingly trying to jump to a NULL function (0x0 according to gdb).
>
>Further testing showed that if I compiled libncurses5 under glibc 2.2.x,
>but using crtn.o from 2.1.3, bash would run fine. Here's the differences
>between 2.1.3 and 2.2.2 of crtn.S:
>
>--- glibc-2.1.3/sparc-linux/obj/csu/crtn.S Mon Feb 19 11:22:02 2001
>+++ glibc-2.2.2/sparc-linux/obj/csu/crtn.S Mon Feb 19 11:19:47 2001
>@@ -10,15 +10,6 @@
> ret
> restore
> END_INIT
>- .section .text
>- .align 4
>- .weak __gmon_start__
>- .type __gmon_start__,#function
>- .proc 020
>-__gmon_start__:
>- !#PROLOGUE# 0
>- retl
>- nop
>
> /*@_init_EPILOG_ENDS*/
> /*@_fini_EPILOG_BEGINS*/
>@@ -29,4 +20,5 @@
>
> /*@_fini_EPILOG_ENDS*/
> /*@TRAILER_BEGINS*/
>+ .weak __gmon_start__
> .ident "GCC: (GNU) 2.95.3 20010125 (prerelease)"
>
>
>Notice in the previous crtn.S, an empty function was declared for
>__gmon_start__ and exported as weak. In the current glibc, this is not
>the case, and the __gmon_start__ symbol is checked for NULL here:
>
>call_gmon_start(void)
>{
> extern void __gmon_start__ (void) __attribute__ ((weak)); /*weak_extern
> (__gmon_start__);*/
> void (*gmon_start) (void) = __gmon_start__;
>
> if (gmon_start)
> gmon_start ();
>}
>
>Currently, __gmon_start__ is only defined if gcrt1.o is linked in.
>
>Here are the symbols for __gmon_start__ in the related binaries:
>
>(bash compiled against glibc 2.1.3)
>0000000000089908 w DF *UND* 0000000000000000 __gmon_start__
>
>(libncurses.so.5 compiled against glibc 2.1.3)
>0000000000034224 w DF .text 0000000000000000 Base __gmon_start__
>
>(libncurses.so.5 compiled against glibc 2.2.2)
>0000000000000000 w D *UND* 0000000000000000 __gmon_start__
>
>
>You can see where the symbol goes missing, yet bash's _init does not do
>tries to execute a non-existant __gmon_start__. I have no idea why this
>isn't affecting other archs. Maybe sparc under glibc 2.1.x was doing
>something weird. I have no idea why ncurses under 2.1.3 has
>__gmon_start__ defined. I've recompiled this several times under our 2.1.3
>based system, which uses gcc-2.95.2 and binutils 2.9.5.0.37, and it still
>defines this symbol (same version of ncurses on both systems).
>
>Any ideas or suggested solutions? If nothing else, I may have to add
>this to initfini.c:
>
>#ifdef __sparc__
>SECTION(".text");
>void __attribute__ ((weak))
>__gmon_start__ (void)
>{
> /* nothing */
>}
>#endif
>
>Just to work around this for now. I don't want to place a hack, but who
>knows, maybe this is the only solution for me.
We had the same problem on PPC, AFAIR it was solved by this change in
binutils/bfd:
2000-10-16 Geoffrey Keating <geoffk@shoggoth.cygnus.com>
* elf32-ppc.c (SYMBOL_REFERENCES_LOCAL): New macro.
(SYMBOL_CALLS_LOCAL): New macro.
(ppc_elf_adjust_dynamic_symbol): Use SYMBOL_CALLS_LOCAL.
(ppc_elf_check_relocs): Use SYMBOL_REFERENCES_LOCAL.
(ppc_elf_finish_dynamic_symbol): Use SYMBOL_REFERENCES_LOCAL.
(ppc_elf_relocate_section): Use flag variable to determine
whether the relocation refers to a local symbol.
Test whether a PLTREL24 reloc will produce a reloc by looking
to see whether a PLT entry was made.
2000-10-14 Geoffrey Keating <geoffk@shoggoth.cygnus.com>
* elf32-ppc.c (ppc_elf_finish_dynamic_symbol): Don't make PLT
entries that could serve as a definition for a weak symbol.
I think the 2000-10-14 one was sufficient, but I don't remember exactly...
Franz.