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