Re: initializing eh

Re: initializing eh

[Olaf Petzold]

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

Re: initializing eh

[H . J . Lu]

On Fri, Mar 02, 2001 at 10:58:57AM +0100, Olaf Petzold wrote:
> > > >> No, they are provided by /usr/lib/crt[in].o.
> > > 
> > > > Interesting, where does it comes from - gcc ?
> > > 
> > > They're part of the standard ELF build environment.
> > Any ideas what is the ELF build env on linux ? At this time I believe gcc
> Well, it seems to come from glibc. Unfortunally there are only:
> 
> /usr/src/glibc-2.2/sysdeps/alpha/elf/crtbegin.S
> /usr/src/glibc-2.2/sysdeps/alpha/elf/crtend.S                                                                                        
> 

/usr/lib/crt[in].o usually come from glibc under Linux.

-- 
H.J. Lu (hjl@gnu.org)

Re: initializing eh

[Olaf Petzold]

> > >> No, they are provided by /usr/lib/crt[in].o.
> > 
> > > Interesting, where does it comes from - gcc ?
> > 
> > They're part of the standard ELF build environment.
> Any ideas what is the ELF build env on linux ? At this time I believe gcc
Well, it seems to come from glibc. Unfortunally there are only:

/usr/src/glibc-2.2/sysdeps/alpha/elf/crtbegin.S
/usr/src/glibc-2.2/sysdeps/alpha/elf/crtend.S                                                                                        

Nothing for other architectures like my intel box.

Regards
Olaf

Re: initializing eh

[Olaf Petzold]

> >> No, they are provided by /usr/lib/crt[in].o.
> 
> > Interesting, where does it comes from - gcc ?
> 
> They're part of the standard ELF build environment.
Any ideas what is the ELF build env on linux ? At this time I believe gcc
produce elf binary files which are loaded by the linux kernel programm loader.
Therefor gcc and (maybe) the linux kernel is my ELF build envirenment. The
linux kernel doesn't bring crt{i|n}.o

Thanks
Olaf

Re: initializing eh

[Olaf Petzold]

> > > The problem is:
> > > unresolved symbol _GLOBAL_OFFSET_TABLE_ 
> > 
> > I think this should be provided by the linker.  It is used to set the PIC
> > register.
> > 
> 
> libgcc.a is compiled with -fPIC. But you don't need it for kernel.
> If it is too hard to workaround, you can recompile libgcc.a without
> -fPIC.
For the kernel module I use:

gcc -I. -I./config -DIN_GCC [...] -Dinhibit_libc -DL_eh -c libgcc2.c -o _eh.o
gcc -I. -I./config -DIN_GCC [...] -Dinhibit_libc -DL_pure -c libgcc2.c -o _pure.o

to get the eh function (and pure virtual) symbols. g++ build some symbols for
lockup by libgcc2 for c++ specific features.

ar cru libkc++.a kmemory.o \	; memory allocator for linux kernel space
	kabort.o \		; abort() for kernel space
	new_op.o new_opnt.o new_opv.o new_opvnt.o \ ; new ops
	del_op.o del_opnt.o del_opv.o del_opvnt.o \ ; delete ops
	new_handler.o \		; new handler
	frame.o \		; I guess frame info for eh
	exception.o		; exception classes
	tinfo.o tinfo2.o 		; rtti
	_eh.o 			; eh from libgcc2.c
	_pure.o			; __pure_virtual from libgcc2.x

This ist the libkc++ support for linux kernel module for eh (later maybe with
streams, vector etc.)

Imo the secret is related to __register/__deregister_frameinfo and the
__xx_LIST__ and __xx_END__ Symbols. All symbols are matched. If I see the
normal linker process:
/usr/lib/gcc-lib/i386-redhat-linux/2.95.2/collect2 -m elf_i386 -dynamic-linker 
	/lib/ld-linux.so.2 -o a /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/cccA5olZ.o -lgcc -lc -lgcc
	/usr/lib/gcc-lib/i386-redhat-linux/2.95.2/crtend.o /usr/lib/crtn.o

crt{i|n} are additional to me. Unfortunally I have no source on it. I've never
found a symbol _init/_fini in the objectfiles produced by the gcc (for elf
sections) - maybee it's predefined by the linker ?

Thanks
Olaf

Re: initializing eh

[H . J . Lu]

On Thu, Mar 01, 2001 at 04:18:20PM +0000, Jason Merrill wrote:
> 
> > The problem is:
> > unresolved symbol _GLOBAL_OFFSET_TABLE_ 
> 
> I think this should be provided by the linker.  It is used to set the PIC
> register.
> 

libgcc.a is compiled with -fPIC. But you don't need it for kernel.
If it is too hard to workaround, you can recompile libgcc.a without
-fPIC.


-- 
H.J. Lu (hjl@gnu.org)

Re: initializing eh

[Jason Merrill]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 681 bytes --]

>>>>> "Olaf" == Olaf Petzold <opetzold@wit.regiocom.net> writes:

> Am Don, 01 Mär 2001 schrieben Sie:
>> >>>>> "Olaf" == Olaf Petzold <opetzold@wit.regiocom.net> writes:
>> 
>> > 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.
>> 
>> No, they are provided by /usr/lib/crt[in].o.

> Interesting, where does it comes from - gcc ?

They're part of the standard ELF build environment.

> The problem is:
> unresolved symbol _GLOBAL_OFFSET_TABLE_ 

I think this should be provided by the linker.  It is used to set the PIC
register.

Jason

Re: initializing eh

[Olaf Petzold]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 715 bytes --]

Am Don, 01 Mär 2001 schrieben Sie:
> >>>>> "Olaf" == Olaf Petzold <opetzold@wit.regiocom.net> writes:
> 
> > 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.
> 
> No, they are provided by /usr/lib/crt[in].o.

Interesting, where does it comes from - gcc ?

The problem is:
unresolved symbol _GLOBAL_OFFSET_TABLE_ 

# nm /usr/lib/crti.o
         U _GLOBAL_OFFSET_TABLE_
         w __gmon_start__
00000000 ? _fini
00000000 ? _init
00000000 t gcc2_compiled.                                                                                                            

Thanks
Olaf

Re: initializing eh

[Jason Merrill]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 299 bytes --]

>>>>> "Olaf" == Olaf Petzold <opetzold@wit.regiocom.net> writes:

> 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.

No, they are provided by /usr/lib/crt[in].o.

Jason

Re: initializing eh

[Olaf Petzold]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2026 bytes --]

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.

Re: initializing eh

[Jason Merrill]

I still think you should be able to call _init from init_module and _fini
from cleanup_module.

Failing that, look at crtstuff again and copy out the __register_frame_info
and __deregister_frame_info bits.

Jason

initializing eh

[Olaf Petzold]

Hello,

some days ago I asked how to initialize the eh for linux kernel. I ripped the
according files (libgcc2.c etc.) from the gcc-2.95.2 dist and from crtstuff.c.
Linux is using elf and dwarf. The problem I can call global C/DTors and can
throw exception but not catch the exceptions. It seems the secrte is related in
the .ini / .fini section of the elf ABI. Anyway, attached is the rewritten
crtstuff for use on linux kernel modules. The linux kernel module loader is
ignoring all elf section - its loading a simple binary archive an locking for
the function symbols int init_module(void) and void cleanup_module(void) and
executes that code. Therefore I have to call the ".init" section in
init_module and the ".fini" section in cleanup_module explicit. 

---- kernel_module.c ---
[...] // global class and def. Module
int init_module(void) {
    frame_dummy();
    __do_global_ctors_aux();

    try {
	Module::create();
	throw int();
    }
    catch(...) {
	WARN("exception catched\n");
	return -1;
    }
    return 0;
}


void cleanup_module(void) {
    Module::remove();
    __do_global_ctors_aux();
}
-------------------
As I mentioned __do_global_Xtors_aux() is working in that manner only eh isn't.
As I can see there are some assums about the position on symbols (like
CTOR_LIST and CTOR_END etc.) for handling with

static  func_ptr __CTOR_LIST__[1] __attribute__ ((__unused__))  = { (func_ptr) (-1) };
static  func_ptr __CTOR_END__[1] = { (func_ptr) 0 };       

static void __do_global_ctors_aux (void)
{
  func_ptr *p;
 
  for (p = __CTOR_END__ - 1; *p != (func_ptr) -1; p--)
    (*p) ();
}

This prinziple doesn't work with eh - there seems to be more secrets? How can I
get it to work ? The compiler is generating the neccessary symbols and
functions __eh_alloc, __throw etc.

Thanks
Olaf

---- kernel_crt.c -----
#include <stddef.h>		// size_t
#include "config/i386/i386.h"       // FIRST_PSEUDO_REGISTER
#include "frame.h"

extern int rtl_printf(const char* fmt, ...); // kernel printf

typedef void (*func_ptr) (void);
typedef unsigned int ui32 __attribute__ ((mode (SI)));

static char __EH_FRAME_BEGIN__[];
static func_ptr __DTOR_LIST__[];
static func_ptr __CTOR_END__[];

static void __do_global_dtors_aux (void)
{
  static func_ptr *p = __DTOR_LIST__ + 1;
  static int completed = 0;

  rtl_printf("__do_global_dtors_aux()\n");
  if (completed)
    return;

  while (*p)
    {
      p++;
      (*(p-1)) ();
    }


  if (__deregister_frame_info)
    __deregister_frame_info (__EH_FRAME_BEGIN__);

  completed = 1;
}

static void frame_dummy (void)
{
  static struct object object;

  rtl_printf("frame_dummy()\n");
  if (__register_frame_info) {
      rtl_printf("call __register_frame_info()\n");
    __register_frame_info (__EH_FRAME_BEGIN__, &object);
  }
}

static void __do_global_ctors_aux (void)
{
  func_ptr *p;

  rtl_printf("__do_global_ctors_aux()\n");
  for (p = __CTOR_END__ - 1; *p != (func_ptr) -1; p--)
    (*p) ();
}

static  func_ptr __CTOR_LIST__[1] __attribute__ ((__unused__))  = { (func_ptr) (-1) };
static  func_ptr __CTOR_END__[1] = { (func_ptr) 0 };

static  func_ptr __DTOR_LIST__[1] = { (func_ptr) (-1) };
static  func_ptr __DTOR_END__[1] __attribute__ ((__unused__))  = { (func_ptr) 0 };

static char __EH_FRAME_BEGIN__[] = { };
static  ui32 __FRAME_END__[] __attribute__ ((__unused__)) = { 0 };
-------------
       

Re: initializing eh

[Jason Merrill]

>>>>> "Olaf" == Olaf Petzold <opetzold@wit.regiocom.net> writes:

> Am Die, 16 Jan 2001 schrieben Sie:
>> Would it work to link in crt[in].o, then simply call _init and _fini from
>> init_module and cleanup_module?

> Unfortunally there are no __init/__fini function.

That's why I mentioned crt[in].o; their sole purpose is to provide those
functions.

Jason

Re: initializing eh

[Olaf Petzold]

Am Die, 16 Jan 2001 schrieben Sie:
> Would it work to link in crt[in].o, then simply call _init and _fini from
> init_module and cleanup_module?

Unfortunally there are no __init/__fini function. There are only some dummy
initializer which I can't call. It seems the asm places these into the elf
sections self. 
At moment I have no overview what does the asm/ld will do on linux/elf.

Regards
Olaf

Re: initializing eh

[Jason Merrill]

Would it work to link in crt[in].o, then simply call _init and _fini from
init_module and cleanup_module?

Jason

Re: initializing eh

[Olaf Petzold]

Hello,

> Try and code
> 
> int b;
> 
> class A {
> public:
> 	A() { b = 1; }
> } a;
> 
> in the kernel and see if b is 1 after you are running.  If it is,
> there isn't much to initialize, merely only the ordering could be
> wrong.  If it is 0, then make it work.  

Well, it gives 0, see comments on source below:

// compile with rtlinux-3
// g++ `rtl-config --cppflags --include` -O0 -c eh_mail.cc
// insmod eh_mail.o ## gives b = 0
//
// using __do_global_Xtors_aux() gives b = 1
// g++ `rtl-config --cppflags --include` -O0 -c eh_mail.cc
// ld -m elf_i386 -static -r -o k_eh.o `g++ -print-file-name=crtbegin.o` eh_mail.o `g++ -print-file-name=crtend.o`
// insmod k_eh.o
#include <rtlinux/rtl_cpp.h>
// [snipp] 
int init_module(void) { // similar to main()
    //__do_global_ctors_aux();
    printk("b = %d\n", b);
    return 0;
}
 
void cleanup_module(void) { // similar to atexit()
    //__do_global_dtors_aux();
}                                                                                                            

> If you add .init support to
> the kernel, things should start working.  Issues will be, when do you
> run ctors.  That, you will have to discusss on the kernel list, not
> here.

As I see, no elf sections will be executed on linux kernel modules, so all
initializing from the .init section I have to do by hand, like
__do_global_Xtors_aux() for global ctors/dtors. This does initialize some
parts of eh?, but not all, since I can't catch the exceptions - It goes directly
to abort() - which is a kernel specif abort (at moment doing nothings, since I
have no idea how to abort a linux kernel module). But this ist kernel mailing
list related.

> After that is working, then you should switch the kernel over to using
> init_priority and have them define all the numbers...  again,
> something for the kernel list.
init_priotity is part of collect2. What does it do ?

Thanks
Olaf

Re: initializing eh

[Mike Stump]

> From: Olaf Petzold <opetzold@wit.regiocom.net>
> To: gcc@gcc.gnu.org
> Date: Thu, 11 Jan 2001 10:01:19 +0100
> Cc: libstdc++@gcc.gnu.org

> I'm interested in the exception handling. I'm writing in C++ for the
> linux kernel therefore I have to bring all components with me. Some
> of the gcc code related to exceptions, rtti I have collected to a
> package. The problem is how to initlialize the eh. For global
> CTors/DTors I have to call __do_global_Xtor_aux(). This does
> initialize some of the eh as well but, it seems not to be enough. I
> can't catch exceptions. The problem is that I can't use the .init /
> .finit section of the elf format - I have to call it by hand.  What
> are the requiered functions. In the code there are some helper
> functions.  Some I can't call explicit.

> What is the way of initializing eh per hand (no elf .init section
> etc.) so I can emulate this for linux kernel?

Try and code

int b;

class A {
public:
	A() { b = 1; }
} a;

in the kernel and see if b is 1 after you are running.  If it is,
there isn't much to initialize, merely only the ordering could be
wrong.  If it is 0, then make it work.  If you add .init support to
the kernel, things should start working.  Issues will be, when do you
run ctors.  That, you will have to discusss on the kernel list, not
here.

After that is working, then you should switch the kernel over to using
init_priority and have them define all the numbers...  again,
something for the kernel list.

Also, when you get the above to work, you have to get it to work, so
that you can have 2 or more modules with this, and have them all
initialize.

Re: initializing eh

[Andrew Macleod]

>> I'm interested in the exception handling. I'm writing in C++ for the linux
>> kernel therefore I have to bring all components with me. Some of the gcc code
>> related to exceptions, rtti I have collected to a package. The problem is how
>> to initlialize the eh. For global CTors/DTors I have to call
>> __do_global_Xtor_aux(). This does initialize some of the eh as well but, it
>> seems not to be enough. I can't catch exceptions. The problem is that I can't
>> use the .init / .finit section of the elf format - I have to call it by hand.
>> What are the requiered functions. In the code there are some helper functions.
>> Some I can't call explicit.

>> What is the way of initializing eh per hand (no elf .init section etc.) so I can
>> emulate this for linux kernel? 

I assume you are using dwarf2 unwind info. ie when you look at your .s file
for a routine with a throw, you have both frame information and
exception table information at the bottom.  (Data tables with __EXCEPTION_TABLE
label and __FRAME_BEGIN__). These are usually in sections labeled
.gcc_except_table and .eh_frame.

You need to call __register_frame_info with  the address of the beginning
of the .eh_frame section, and a pointer to a small hunk of memory 
for the frame objec (struct object in frame.h). You should do this just before
calling your static constructors. 
__deregister_frame_info should be called with the address of the beginning 
of .eh_frame section after all the static destructors have been run.

Both are declared in frame.c.

Andrew

initializing eh

[Olaf Petzold]

Hello,

I'm interested in the exception handling. I'm writing in C++ for the linux
kernel therefore I have to bring all components with me. Some of the gcc code
related to exceptions, rtti I have collected to a package. The problem is how
to initlialize the eh. For global CTors/DTors I have to call
__do_global_Xtor_aux(). This does initialize some of the eh as well but, it
seems not to be enough. I can't catch exceptions. The problem is that I can't
use the .init / .finit section of the elf format - I have to call it by hand.
What are the requiered functions. In the code there are some helper functions.
Some I can't call explicit.

What is the way of initializing eh per hand (no elf .init section etc.) so I can
emulate this for linux kernel? 

Thanks
Olaf