[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

the [de]register_frame_info definitions issues on Alpha




Hello everybody, 

I have tried the gdb from (Mikolaj J. Habryn) and got the following
error:

./gdb: error in loading shared libraries
: undefined symbol: __deregister_frame_info

Contrary to what has been said previously, the _register_frame_info
problem  is probably  a serious issue even on Alpha, it is a matter of 
backwards compatibility and binary compatibility with other
Linux/Alpha systems (on i386 the fact egcs cannot be used to compile
the libc or other shared lib should be also corrected). 

I am not an expert on these issues so I may be wrong but I have
observed that:
- we have HLU patches added to egcs so that in 
gcc-lib/.../crtbegin.o, there is some init code to register (via
a call to __register_frame_info) a structure related to C++ exception
handling.
crtbegin.o is linked in every shared lib and in every executable (even 
those that do not contain any C++ code).
- the function __register_frame_info is defined in libgcc.a(frame.o)
- libc is linked with libgcc.a and so define __register_frame_info if
compiled with the last gcc package
- every executable linked with our current libc will assume
register_frame_info is defined in libc and will not put it into the
executable, and it will depends on this symbol.
- if the executable is run on a system where libc has  not compiled with 
out customegcs, it will fail with the  "undefined symbol:
__deregister_frame_info" error. That means we cannot run binaries
compiled on Debian on Redhat, and if even Debian people will render
their system unusable if they do not upgrade their libc before any
package compiled with the current egcs/libc combination. They are no
dependencies present to take account of that.

I think the  right solution is to patch the crtbegin file in egcs, to
include a weak  prototype of [de]register_frame_info, setting it to
a dummy function. Looking at the code I think this was the intention
of the author to do something similar because he included weak prototypes
of the symbol, and do not call the function int them if they point to
"zero". But he forgot to actually put a default definition, so the weak
protype is ingored in this cases.

Here is a patch, what he should solve:
- binaries compatibility should be ensured with other systems
- while upgrading their system, current debian users do not risk to
render it unbootable.

I think we should try to find any package (or at least in the base
system) with an executable or a shared lib depending on the
[de]register_frame_info symbols and recompile them with  egcs patched
as below. 

The good thing is that even executables compiled under the bad
egcs/libc combination will run under such a new libc/egcs as the libc will
include a weak definition of the symbol. So this would correspond to a 
"be generous in what executables you accept, and be careful in what you 
generate"


Any comments? We probably need a news gcc ASAP.

Loic

here is the patch (must be applied after the other ones of the Debian 
source), for x86 a similar modif shoudl be made in crtstuff.c :

--- gcc/config/alpha/crtbegin.asm	Sun Jan 24 10:48:50 1999
+++ /home/lprylli/divers-patch/crtbegin.asm	Sun Jan 24 10:35:21 1999
@@ -189,4 +189,18 @@
 	.end __do_frame_takedown
 
 .weak __register_frame_info
+	.align 3
+	.ent __register_frame_info
+__register_frame_info:
+        .frame $30,0,$26,0
+        .prologue 0
+	ret
+	.end __register_frame_info
 .weak __deregister_frame_info
+	.align 3
+	.ent __deregister_frame_info
+__deregister_frame_info:
+        .frame $30,0,$26,0
+        .prologue 0
+	ret
+	.end __deregister_frame_info


Reply to: