This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: initializing eh
Am Don, 01 Mär 2001 schrieben Sie:
> I still think you should be able to call _init from init_module and _fini
> from cleanup_module.
The crtstuff hasn't such functions. Symbols are
# nm `g++ -print-file-name=crtbegin.o`
00000000 ? __CTOR_LIST__
00000000 ? __DTOR_LIST__
00000000 ? __EH_FRAME_BEGIN__
w __deregister_frame_info
00000000 t __do_global_dtors_aux
w __register_frame_info
00000004 d completed.4
00000060 t fini_dummy
00000008 d force_to_data
00000070 t frame_dummy
00000000 t gcc2_compiled.
000000a0 t init_dummy
00000000 b object.11
00000000 d p.3
# nm `g++ -print-file-name=crtend.o`
00000000 ? __CTOR_END__
00000000 ? __DTOR_END__
00000000 ? __FRAME_END__
w __deregister_frame_info
00000000 t __do_global_ctors_aux
w __register_frame_info
00000000 d force_to_data
00000000 t gcc2_compiled.
00000030 t init_dummy
init_dummy and fini_dummy are local/static symbols. As I did understood elf
there are several .ini/.fini sections possible - all will be excecuted by the
os programm loader before main() / after exit() (__exit(), atexit() ????).
init_dummy #1 calls frame_dummy();,
init_dummy #2 calls __do_global_ctors_aux(); !!
I assume, that xxx_BEGIN and xx_LIST are on the begin of the binary and
xxx_END at the end. Between this are the frame infos for eh. As I read the
sources the unwinding prozess increments the pointer from end to begin and
calls all registred functions. Therefore a simple wrting of symbols doesn't
solve the problem - hopefully I'm wrong. In that case I don't know a way.
> Failing that, look at crtstuff again and copy out the __register_frame_info
> and __deregister_frame_info bits.
It's in frame.{h|c}. It's compiled and linked to the linux kernel module. All
symbold are resolved by the kernel module loader - if it fails the module isn't
started.
Regards
Olaf
PS: If you are interested in details I can send you the dist.