This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
__gmon_start__ issues between 2.1.x and 2.2.x on sparc(?)
- To: GNU C Library <libc-alpha at sourceware dot cygnus dot com>
- Subject: __gmon_start__ issues between 2.1.x and 2.2.x on sparc(?)
- From: Ben Collins <bcollins at debian dot org>
- Date: Mon, 19 Feb 2001 12:37:40 -0500
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.
--
-----------=======-=-======-=========-----------=====------------=-=------
/ Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \
` bcollins@debian.org -- bcollins@openldap.org -- bcollins@linux.com '
`---=========------=======-------------=-=-----=-===-======-------=--=---'