This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |