Re: some problems when using gcc3.0 instead of gcc2.95.3

[Kai Ruottu <kai dot ruottu at luukku dot com>]

On Wed, 27 Jun 2001 12:09:41 +0800
"Cliff Tsai" <clifftsai@axisoft.com> wrote:

>     I've build gcc3.0 for ARM under cygwin.

 For 'arm-coff', 'arm-pe' or what else not using the 'crtbegin.o' and
'crtend.o' ?

>     And what "__EH_FRAME_BEGIN__" and "__EH_FRAME_END__"  mean?

 They are defined in 'gcc/crtstuff.c', but not so well in 'gcc/libgcc2.c'
(in '__main()'), which the COFF-like targets now use...

 Quicly looked they seem to mean the start and end addresses of the new
'.eh_fram'-section. For instance a 'm68k-coff' targeted object used to
have only three sections like :

hi_cpu32.o:     file format coff-m68k

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         0000004c  00000000  00000000  0000008c  2**2
                  CONTENTS, ALLOC, LOAD, RELOC, CODE
  1 .data         0000003e  0000004c  0000004c  000000d8  2**2
                  CONTENTS, ALLOC, LOAD, RELOC, DATA
  2 .bss          00000000  0000008a  0000008a  00000000  2**2
                  ALLOC, NEVER_LOAD

if compiled with gcc-2.95.x and from a C++ source, but now it has one
section more:

hi_cpu32-edk.o:     file format coff-m68k

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         0000004c  00000000  00000000  000000b4  2**2
                  CONTENTS, ALLOC, LOAD, RELOC, CODE
  1 .data         00000000  0000004c  0000004c  00000000  2**2
                  ALLOC, LOAD, DATA
  2 .bss          00000000  0000004c  0000004c  00000000  2**2
                  ALLOC, NEVER_LOAD
  3 .eh_fram      0000003a  0000004c  0000004c  00000100  2**2
                  CONTENTS, ALLOC, LOAD, RELOC, DATA

>     I don't see them when using gcc2.95.3.
>     My solution is PROVIDE a un-used address for them in the linker script!

 Also I'm trying to find a solution into this. My thought is that the
'__main()' in 'libgcc2.c' should define these addresses, but haven't got
any patches ready...

 My first thought was that if the 'crtbegin.o' and 'crtend.o' have these,
why not just enable building them using the

  EXTRA_PARTS = crtbegin.o crtend.o

in the 'tmake_file' and adding these files into the 'ENDFILE_SPEC' and
'STARTFILE_SPEC' in the 'tm_file'... But in the 'm68k-coff' case this seemed
to increase the executable size with 2620 bytes although the sizes for the
additional files weren't very big...

   text	   data	    bss	    dec	    hex	filename
      8	      0	      0	      8	      8	crtbegin.o
      8	      4	      0	     12	      c	crtend.o

 Anyway the additional files define the symbols and linking succeeds with
the original linker script...

crtbegin.o:
00000000 b .bss
00000000 ? .ctors
00000000 d .data
00000004 ? .dtors
00000008 ? .eh_fram
00000000 t .text
00000000 ? __CTOR_LIST__
00000004 ? __DTOR_LIST__
00000008 ? __EH_FRAME_BEGIN__
00000000 t __gnu_compiled_c
00000000 d force_to_data
00000000 t gcc2_compiled.

crtend.o:
00000000 b .bss
00000000 ? .ctors
00000000 d .data
00000004 ? .dtors
00000008 ? .eh_fram
00000000 t .text
00000000 ? __CTOR_END__
00000004 ? __DTOR_END__
00000008 ? __FRAME_END__
00000000 t __gnu_compiled_c
00000000 d force_to_data
00000000 t gcc2_compiled.

 Still wondering what to do with this...

 Cheers, Kai

PS. gcc-3.0.1 maybe has some problems with C++ and the 'm68k-coff' target,
I got weird errors of "template with C linkage", but perhaps my C++ headers
just were old (didn't update the '$prefix/include/g++-v3'). So the RedHat
EDK-00221-version presents the new 'feature' here...


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