Re: initializing eh

[Olaf Petzold <opetzold at wit dot regiocom dot net>]

Am Fre, 12 Jan 2001 schrieben Sie:
> >> Hello Andrew,
> >> 
> >> thanks for your answer. I've used code from gcc-2.95.2, since the upcoming
> >> gcc-3.0 has more buildin functions. My first try was to take the eh code from
> >> gcc-3 and compiled with gcc-2.95.x - there was a __buildin_init_dwarf or
> >> similar missing. Nevertheless, I thing (not for shure) that the gcc-2.95.2 is
> >> using dwarf debug info. Do you know more about this ?
> 
> A lot depends on your target and whether its already implemented for that
> target or not. If it isn't using dwarf2, then it would be using
> setjmp/longjmp, and it should just work by default.

Well, it seems I'm using dwarf2. It's on linux/i386. Using this in user mode.
The problem is, the linux kernel module is a simple binary archive created by
ld -m elf_i386 -static -o myModule myObjects. The linux kernel module loader
resolves the symbols and executes the code in the init_module() function. On
removing the kernel module laoder is calling the cleanup_module() function.
Therefore init_module()/cleanup_module() is similar to the .init/.fini section
of elf and no asm is necessaray/posiible to the the eh functions to the
sections. The conclusion could be, I can use dwarf od setjump/longjump.
Nevertheless I guess using dwarf is the better way to be in principle
"compatible" with the user mode behavior. BTW this means that I can't put user
mode module in the kernel.

> >> In libgcc2.c there are some dummy functions - is that the way of initializing 
> >> eh as you describted ? I was not able to call these dummy functions per hand 
> >> (maybee my fault). Which of the dummies is the responsible of that ? 

> IF your port uses crtstuff.c, then some ports are configured to automatically
> set up the frame information via calls to frame_dummy, but that is static
> to crtstuff.c since init_dummy is supopse to automatically be put in
> the .init section and get called... 

Well. linux/i386 is using crtstuff:

# gcc -I.. -I../src -v user_test.cc -o user_test
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.95.2/specs
gcc version 2.95.2 19991024 (release)
 /usr/lib/gcc-lib/i386-redhat-linux/2.95.2/cpp -lang-c++ -v -I.. -I../src -D__GNUC__=2 -D__GNUG__=2 -D__GNUC_MINOR__=95 -D__cplusplus -D__ELF__ -Dunix -D__i386__ -Dlinux -D__ELF__ -D__unix__ -D__i386__ -D__linux__ -D__unix -D__linux -Asystem(posix) -D__EXCEPTIONS
-Acpu(i386) -Amachine(i386) -Di386 -D__i386 -D__i386__ user_test.cc /tmp/cchbI5hK.ii
GNU CPP version 2.95.2 19991024 (release) (i386 Linux/ELF)
[...]
 /usr/lib/gcc-lib/i386-redhat-linux/2.95.2/cc1plus /tmp/cchbI5hK.ii -quiet
-dumpbase user_test.cc -version -o /tmp/cck63NHr.s GNU C++ version 2.95.2
19991024 (release) (i386-redhat-linux) compiled by GNU C version 2.95.2
19991024 (release).  as -V -Qy -o /tmp/cciPO5be.o /tmp/cck63NHr.s GNU assembler
version 2.10.90 (i386-redhat-linux) using BFD version 2.10.0.18 
/usr/lib/gcc-lib/i386-redhat-linux/2.95.2/collect2 -m elf_i386 -dynamic-linker
/lib/ld-linux.so.2 -o user_test /usr/lib/crt1.o /usr/lib/crti.o
/usr/lib/gcc-lib/i386-redhat-linux/2.95.2/crtbegin.o
-L/usr/lib/gcc-lib/i386-redhat-linux/2.95.2 /tmp/cciPO5be.o -lgcc -lc -lgcc
/usr/lib/gcc-lib/i386-redhat-linux/2.95.2/crtend.o /usr/lib/crtn.o            
                                            
I assume, I can't call init_dummy direct, or ?
 
> I've been working on a draft of a document about how to get EH
> working for a port, which I've attached at the bottom. You can have a read
> through it and see if its of any help. I'd appreciate and feedback
> you have as well, since it is a work in progress :-)

Over the weekend I will read this.

Thanks
Olaf