RE: objcopy problems
"Jaysen Roper" <[email protected]> Wed, 13 Aug 2008 10:09:06 +0100
| Newsgroups | gmane.comp.hardware.motorola.microcontrollers.coldfire |
|---|---|
| Message-ID | <001d01c8fd24$3d41c6b0$b7c55410$@com> |
Nearly there Ed, These are the linker errors now, Ive look em all up and its because newlib doesn’t implement these because they are so different between targets and developers need to do their own to suit the target. I presume you have these already implemented for pluto6? If so can I have them via Lee please. Thanks Jaysen C:\Program Files\CodeSourcery\Sourcery G++ Lite\m68k-elf\lib\m5206e\libg.a(lib_a-sbrkr.o): In function `_sbrk_r': sbrkr.c:(.text+0x10): undefined reference to `sbrk' C:\Program Files\CodeSourcery\Sourcery G++ Lite\m68k-elf\lib\m5206e\libg.a(lib_a-writer.o): In function `_write_r': writer.c:(.text+0x18): undefined reference to `write' C:\Program Files\CodeSourcery\Sourcery G++ Lite\m68k-elf\lib\m5206e\libg.a(lib_a-closer.o): In function `_close_r': closer.c:(.text+0x10): undefined reference to `close' C:\Program Files\CodeSourcery\Sourcery G++ Lite\m68k-elf\lib\m5206e\libg.a(lib_a-fstatr.o): In function `_fstat_r': fstatr.c:(.text+0x14): undefined reference to `fstat' C:\Program Files\CodeSourcery\Sourcery G++ Lite\m68k-elf\lib\m5206e\libg.a(lib_a-isattyr.o): In function `_isatty_r': isattyr.c:(.text+0x10): undefined reference to `isatty' C:\Program Files\CodeSourcery\Sourcery G++ Lite\m68k-elf\lib\m5206e\libg.a(lib_a-lseekr.o): In function `_lseek_r': lseekr.c:(.text+0x18): undefined reference to `lseek' C:\Program Files\CodeSourcery\Sourcery G++ Lite\m68k-elf\lib\m5206e\libg.a(lib_a-readr.o): In function `_read_r': readr.c:(.text+0x18): undefined reference to `read' cs-make: *** [demo.elf] Error 1 -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Edwin Langley Sent: 12 August 2008 16:40 To: Jaysen Roper Subject: RE: [ColdFire] objcopy problems Hi Jaysen I have reproduced the problems just as you describe them in this thread. Here are some work arounds to produce an ieee format output file with debug information, using our .a library files as provided in the dev kit. > I've tried a full rebuild with the new ELF toolchain but get architecture > problems with our libraries at ld stage. > The example below is a single example, every .o file in our library (3rd > party, no src) produces this error. > > m68k-elf-ld: m68k:68020 architecture of input file > `/heber/pluto6/libs/gnu/pluto6\libdbug.a(dbug-outbyte.o)' is incompatible > with m68k:isa-a:nodiv output You are on the right track here, a full rebuild is necessary with a newer ELF toolchain. I'm afraid I didn't get the architecture errors you describe at link time. I used the Codesourcery toolchain which we are using for Pluto 8, the download was called freescale-coldfire-4.1-32-m68k-elf.exe. Please ensure you are using at least a similar toolchain version from Codesourcery (they update it often and don't seem to offer previous releases for download, at least for free, which is fair enough). Also ensure the library .a files are as provided in the dev kit. Try downloading the latest libraries from www.heber.co.uk if necessary. To Rebuild the demo project with the ELF toolchain some changes were required to the commands and the target name in the makefile. Also some extra sections were needed in the linker script: .data : AT (ADDR(.shbss) + SIZEOF(.shbss)) { vars_start = .; *(.data) - vars_end = .; +/* vars_end = .; */ } > ram + .rodata : AT (ADDR(.shbss) + SIZEOF(.shbss) + SIZEOF(.data)) + { + *(.rodata) + *(.rodata.str1.1) + vars_end = .; + } > ram + .eh_frame : + { + *(.eh_frame) + } > ram Try this on the unaltered demo project in the dev kit. Once an ELF file is built the objcopy command still produces the errors you mentioned: > C:\Games\heber\demo>m68k-elf-objcopy --debugging -O ieee -R .id -R ..system > demo.elf demo.iee > demo.cof: .stab: stab entry 1 is corrupt, strx = 0xd3000000, type = 8 > demo.cof: .stab: stab entry 3 is corrupt, strx = 0x0, type = 37 > demo.cof: .stab: stab entry 4 is corrupt, strx = 0x0, type = 84 > demo.cof: .stab: stab entry 5 is corrupt, strx = 0x0, type = 110 > .... These stab entries are coming from the lib .a files provided with the old COFF toolchain (libgcc.a, libstdc++.a etc) which are still being explicitly linked in by the makefile. So change the makefile to use the libs which come with the new toolchain: -lstd= ../../libs/gnu/$(target) +lstd= C:\m68k-codesourcery\lib\gcc\m68k-elf\4.1.1\m5206e +lstd2= C:\m68k-codesourcery\m68k-elf\lib\m5206e (Add -L$(lstd2) to the linker command) -gnu= -lc -ldbug -lgcc -lg -lm -liberty -lstdc++ +gnu= -lg -lc -lgcc -lm -liberty -lstdc++ After that I ran the objcopy command with the --debugging switch and it worked fine. If you need anymore detail let Lee know downstairs in support and I'll pass it along. Cheers Ed Langley Software Engineer Heber Ltd. Registered Office: Belvedere Mill, Chalford, Stroud. GL6 8NT, UK. Registered England and Wales: 1744505 Tel: +44 (0) 1453 88 6000 www.heber.co.uk --- [email protected] Send a post to the list. [email protected] Join the list. [email protected] Join the list in digest mode. [email protected] Leave the list. --- [email protected] Send a post to the list. [email protected] Join the list. [email protected] Join the list in digest mode. [email protected] Leave the list.