Re: __EH_FRAME_BEGIN__ setup?

[Kai Ruottu <karuottu at mbnet dot fi>]

Haven't really had time to answer earlier...

Toralf Lund wrote:

> Kai Ruottu wrote:
>
> > Toralf Lund wrote:
> >
> > > With recent versions of gcc, apparently  __EH_FRAME_BEGIN__ has to be 
> > > defined in the linker script. What is it, and how am I supposed to 
> > > initialise it.
> >
> >  Please use the premade linker scripts coming with newlib as models...
>
> I checked those before I asked, obviously, but it's far from clear based 
> on these what it all means, or where I ought to put the setup. The 
> different linker scripts don't even put "eh frame" stuff in the same 
> output section...

 You must use ELF now because this __EH_FRAME_BEGIN__ neither the '.eh_frame'
section are not used with the COFF format at all...

 If you however are using 'm68k-coff', how on earth you can get these?

 In which modules this section is included?  What if you try :

    objdump -h <the_modules> | grep eh_frame

for your startup (crt0.o), the C library (libc.a), the C++ library
(libstdc++.a), your own compiled modules etc., do some of them have this
extra section?

 A quick check in my 'lib*.a' for 'm68k-coff' tools didn't show any instances
of this section meanwhile starting from the very base 'crtbegin.o/crtend.o'
(not used with the 'm68k-coff' format) startups, the '.eh_frame' section seems
to be present everywhere with the 'm68k-elf' format.

F:\usr\local\lib\gcc-lib\m68k-elf\3_1.1>m68k-elf-objdump -h crtbegin.o

crtbegin.o:     file format elf32-m68k

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         0000009c  00000000  00000000  00000034  2**2
                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
  1 .data         00000008  00000000  00000000  000000d0  2**2
                  CONTENTS, ALLOC, LOAD, RELOC, DATA
  2 .bss          0000001c  00000000  00000000  000000d8  2**2
                  ALLOC
  3 .ctors        00000004  00000000  00000000  000000d8  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  4 .dtors        00000004  00000000  00000000  000000dc  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  5 .eh_frame     00000000  00000000  00000000  000000e0  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  6 .jcr          00000000  00000000  00000000  000000e0  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  7 .fini         00000006  00000000  00000000  000000e0  2**0
                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
  8 .init         00000006  00000000  00000000  000000e6  2**0
                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
  9 .comment      00000028  00000000  00000000  000000ec  2**0

 However there maybe once was a serious bug in the GCC's 'm68k-coff' target
configuration files and this section erroneously being added...

 It is always recommended to have the GNU manuals and to search from them. In
this 'EH_FRAME' keyword search case the "GCC Internals" gave :

----------------------- clip ------------------------------------------------
10.20.9 Assembler Commands for Exception Regions

This describes commands marking the start and the end of an exception region.

EH_FRAME_SECTION_NAME
  If defined, a C string constant for the name of the section containing
  exception handling frame unwind information. If not defined, GCC will provide
  a default definition if the target supports named sections. `crtstuff.c' uses
  this macro to switch to the appropriate section.

  You should define this symbol if your target supports DWARF 2 frame unwind
  information and the default definition does not work.
----------------------- clip ------------------------------------------------

 AFAIK the 'm68k-coff' target doesn't support DWARF 2, the DWARF debug formats
are usually related to the ELF object format, not used with pure COFF at all...

 Please, please build the GCC manuals from your GCC sources, for instance into
the common PDF format and then use your Acrobat Reader or something to search
these manuals !  Usually searching for those mystical things will give some
clue.

 So you most probably have something badly wrong in your toolchain...

Cheers, Kai


------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com