This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: Versioning mess proved!!!
- To: Ulrich Drepper <drepper at redhat dot com>
- Subject: Re: Versioning mess proved!!!
- From: Franz Sirl <Franz dot Sirl-kernel at lauterbach dot com>
- Date: Sun, 1 Oct 2000 13:47:14 +0200
- Cc: Jack Howarth <howarth at fuse dot net>,libc-alpha at sourceware dot cygnus dot com,aj at suse dot de
- References: <39D50E20.263F646F@fuse.net> <00093002244100.04124@enzo.bigblue.local> <m3wvftmqor.fsf@otr.mynet.cygnus.com>
On Sun, 01 Oct 2000, Ulrich Drepper wrote:
> Franz Sirl <Franz.Sirl-kernel@lauterbach.com> writes:
> > Hmm, it segfaults in call_gmon_start cause __gmon_start__ gets relocated
> > and thus is no longer NULL.
>
> Why is this bad? I know it's not wanted but why should a performed
> relocation cause the trouble? Is there an incorrect implementation of
> __gmon_start__ somewhere?
Well, I wish I knew exactly what happens...
It seems that under some combinations of glibc-2.1.3/glibc-2.2 and thus a
mixture of NOTYPE/WEAK and FUNC/WEAK definitions the start of __gmon_start__
gets relocated, whereas it should stay a 0. It get's relocated to an absolute
branch to address 0. Since now the test for 0 in call_gmon_start fails,
__gmon_start__ gets called and then branches to 0 which nicely segfaults.
> > murx22: 0001e994 08114 R_PPC_GLOB_DAT 00000000 __gmon_start__
> > + 0
> > murx22: 129: 00000000 0 NOTYPE WEAK DEFAULT UND __gmon_start__
> > murx22: 248: 00000000 0 NOTYPE WEAK DEFAULT UND __gmon_start__
>
> This is what we have on x86 as well and it works just fine. I need
> some more information.
But do you get the NOTYPE/WEAK under glibc-2.1.3 as well? And under earlier
glibc-2.1.9x snapshots? Actually I think you fixed it with that patch for PPC:
2000-08-28 Ulrich Drepper <drepper@redhat.com>
* sysdeps/unix/sysv/linux/powerpc/Makefile [$(subdir)==csu]
(CFLAGS-initfini.s): Add -DWEAK_GMON_START.
but then the dummy function in initfini.c go completely removed with this
patch:
2000-09-10 Ulrich Drepper <drepper@redhat.com>
* sysdeps/generic/initfini.c: Rewrite slightly to get rid of the
ugly GMON_WEAK_START hack.
Patch by Philip Blundell <philb@gnu.org>.
and WEAK_GMON_START is now completely unused.
I'm not sure about the implications, but maybe this can be solved with the
appended patch? At least it shouldn't hurt to be explicit about the type of
__gmon_start__ and it looks a bit cleaner that way. I'll try that now on PPC.
Franz.
* include/libc-symbols.h (type_function): New macro.
* csu/defs.awk: Use it.
Index: csu/defs.awk
===================================================================
RCS file: /cvs/glibc/libc/csu/defs.awk,v
retrieving revision 1.4
diff -u -p -r1.4 defs.awk
--- csu/defs.awk 2000/07/25 22:17:21 1.4
+++ csu/defs.awk 2000/10/01 11:36:54
@@ -24,4 +24,5 @@ END {
print "#include <libc-symbols.h>";
print "weak_extern (__gmon_start__)";
+ print "type_function (__gmon_start__)";
}
Index: include/libc-symbols.h
===================================================================
RCS file: /cvs/glibc/libc/include/libc-symbols.h,v
retrieving revision 1.19
diff -u -p -r1.19 libc-symbols.h
--- include/libc-symbols.h 2000/07/18 17:12:50 1.19
+++ include/libc-symbols.h 2000/10/01 11:36:54
@@ -90,6 +90,10 @@
# define weak_function __attribute__ ((weak))
# define weak_const_function __attribute__ ((weak, __const__))
+/* Explicitly mark a symbol as function. */
+# define type_function(symbol) _type_function(symbol)
+# define _type_function(symbol) asm (".type " __SYMBOL_PREFIX #symbol ",@function");
+
# ifdef HAVE_WEAK_SYMBOLS
/* Define ALIASNAME as a weak alias for NAME.
@@ -114,6 +118,9 @@
# endif
#else /* __ASSEMBLER__ */
+
+# define type_function(symbol) \
+ .type C_SYMBOL_NAME (symbol),@function
# ifdef HAVE_ASM_SET_DIRECTIVE
# define strong_alias(original, alias) \