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: Versioning mess proved!!!


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)		\

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