This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: __gmon_start__ issues between 2.1.x and 2.2.x on sparc(?)


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]