objcopy problems

coldfire@... Send a post to the list. coldfire-join@... Join the list. coldfire-digest@... Join the list in digest mode. coldfire-leave@... Leave the list.

X-SpamDetect-Info: ------------- Start ASpam results ---------------
X-SpamDetect-Info: This message may be spam. This message BODY has been altered to show you the spam information
X-SpamDetect: **********: 10.400001 From3consonants=0.3, Share Market Scam=2.0, SPF Soft=3.0, DodgySource=2.0, SPF Default Fail=2.5, X-Verify-SMTP present=0.6
X-SpamDetect-Info: ------------- End ASpam results -----------------

Jaysen Roper wrote:
The coff format is not used that much these days with the m68k target. I think
all are ELF.

I suggest you take a look at the Codesourcery tools available for download
from their web site. Install those tools and see how the objcopy in their
package goes. It may not crash.

Regards
Chris
---
coldfire@...              Send a post to the list.
coldfire-join@...        Join the list.
coldfire-digest@...    Join the list in digest mode.
coldfire-leave@...     Leave the list.

I installed the elf toolchain from codesourcery, it went on easily enough
and after sorting out PATH environments it works fine alongside our original
gnu install. I can use both toolchains independently.

But the elf-objcopy doesn't work when used with our coff-build (although it
doesn't crash)

C:\Games\heber\demo>m68k-elf-objcopy --debugging -O ieee -R .id -R .system
demo.cof 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
demo.cof: .stab: stab entry 6 is corrupt, strx = 0x0, type = 162
demo.cof: .stab: stab entry 7 is corrupt, strx = 0x0, type = 218
demo.cof: .stab: stab entry 8 is corrupt, strx = 0x1, type = 23

---------------------------

So it looks like I cant mix toolchain tools. (mix coff compilers and elf
objcopy)

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

--------------------

So It looks like my libraries are compiled as 68020 (and I cant change that)
And the codesourcery tools are hardcoded to  isa-a (coldfire)

Is there an old coff-objcopy out there I could use? I don't have the means
to rebuild it though. My version is 2.9.1 (1997)



Thanks
Jaysen




-----Original Message-----
From: coldfire-bounce@... [mailto:coldfire-bounce@...] On
Behalf Of Chris Johns
Sent: 09 August 2008 04:08
To: Jaysen Roper
Subject: Spam:**********, Re: [ColdFire] objcopy problems

X-SpamDetect-Info: ------------- Start ASpam results ---------------
X-SpamDetect-Info: This message may be spam. This message BODY has been
altered to show you the spam information
X-SpamDetect: **********: 10.400001 From3consonants=0.3, Share Market
Scam=2.0, SPF Soft=3.0, DodgySource=2.0, SPF Default Fail=2.5, X-Verify-SMTP
present=0.6
X-SpamDetect-Info: ------------- End ASpam results -----------------

Jaysen Roper wrote:
The coff format is not used that much these days with the m68k target. I
think
all are ELF.

I suggest you take a look at the Codesourcery tools available for download
from their web site. Install those tools and see how the objcopy in their
package goes. It may not crash.

Regards
Chris
---
coldfire@...              Send a post to the list.
coldfire-join@...        Join the list.
coldfire-digest@...    Join the list in digest mode.
coldfire-leave@...     Leave the list.



---
coldfire@...              Send a post to the list.
coldfire-join@...        Join the list.
coldfire-digest@...    Join the list in digest mode.
coldfire-leave@...     Leave the list.

X-SpamDetect-Info: ------------- Start ASpam results ---------------
X-SpamDetect-Info: This message may be spam. This message BODY has been altered to show you the spam information
X-SpamDetect: **********: 10.400001 From3consonants=0.3, SPF Soft=3.0, Symbol & DodgySrc=2.0, DodgySource=2.0, SPF Default Fail=2.5, X-Verify-SMTP present=0.6
X-SpamDetect-Info: ------------- End ASpam results -----------------

Jaysen Roper wrote:
For my tools which are rtems ones the BFD support for coff is built into the
elf build of objcopy. I suspect the Codesourcery tools are the same. This
looks like a bug in the old compiler and the coff debug information.

$ /opt/rtems-4.9/bin/m68k-rtems4.9-objcopy
     [ snip ]
/opt/rtems-4.9/bin/m68k-rtems4.9-objcopy: supported targets: elf32-m68k
coff-m68k versados ieee a.out-zero-big elf32-l             ittle elf32-big
srec symbolsrec tekhex binary ihex

> 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 need to provide the command line used to build the object file. At a guess
it looks like the options you used to build the dbug-outbyte.o are wrong.
Please try:

$ m68k-elf-gcc --target-help

and check your compile options.

> So It looks like my libraries are compiled as 68020 (and I cant change that)
> And the codesourcery tools are hardcoded to  isa-a (coldfire)

I doubt this. I think they will have multilib'ed their tools.

>
> Is there an old coff-objcopy out there I could use? I don't have the means
> to rebuild it though. My version is 2.9.1 (1997)
>

Given the age of the tools you are using it will be difficult.

Regards
Chris
---
coldfire@...              Send a post to the list.
coldfire-join@...        Join the list.
coldfire-digest@...    Join the list in digest mode.
coldfire-leave@...     Leave the list.

Ahh, big sigh.

The libstd / libc / libm and other standard libraries are multilib'ed (I had
to look that up) but the board specific libs are not.
They only exist in one place, we don't even have a non-debug build of the
board specific libs from the vendor. And no source to rebuild with. Ho hum.
These are the .o's and .a's that are coming up as 68020 arch.


Perhaps these 2 screen dumps will shed some light....

--------------------------------------------------------
C:\Games\heber\demo>make demo.o
m68k-coff-gcc -c -I.  -I/heber/pluto6/libs/peripherals/pluto6/81-16631-10
-I/heber/pluto6/libs/hardware/pluto6/81-16616-
16 -I/heber/pluto6/libs/customperipherals/pluto6/81-17315-5
-I/heber/pluto6/libs/interface/pluto6/81-17292-7 -fno-inline
 -Wcast-align -Wcast-qual -Wall -O0 -m5200 -msoft-float -D__mod2__=void
-DIN_GCC=1 -nostdinc -gstabs+ demo.c -o demo.o

C:\Games\heber\demo>m68k-coff-objdump -x demo.o |more

demo.o:     file format coff-m68k
demo.o
architecture: m68k:68020, flags 0x00000031:
HAS_RELOC, HAS_SYMS, HAS_LOCALS
start address 0x00000000
--------------------------------------------------------

C:\Games\heber\demo>cs-make demo.o
m68k-elf-gcc -c -I.  -I/heber/pluto6/libs/peripherals/pluto6/81-16631-10
-I/heber/pluto6/libs/hardware/pluto6/81-16616-1
6 -I/heber/pluto6/libs/customperipherals/pluto6/81-17315-5
-I/heber/pluto6/libs/interface/pluto6/81-17292-7 -fno-inline
-Wcast-align -Wcast-qual -Wall -O0 -m5200 -msoft-float -D__mod2__=void
-DIN_GCC=1 -nostdinc -gstabs+ demo.c -o demo.o

C:\Games\heber\demo>m68k-elf-objdump -x demo.o |more

demo.o:     file format elf32-m68k
demo.o
architecture: m68k:isa-a:nodiv, flags 0x00000011:
HAS_RELOC, HAS_SYMS
start address 0x00000000


-------------------------------------------------------------------





-----Original Message-----
From: coldfire-bounce@... [mailto:coldfire-bounce@...] On
Behalf Of Chris Johns
Sent: 11 August 2008 23:00
To: Jaysen Roper
Subject: Spam:**********, Re: Spam:**********, Re: [ColdFire] objcopy
problems

X-SpamDetect-Info: ------------- Start ASpam results ---------------
X-SpamDetect-Info: This message may be spam. This message BODY has been
altered to show you the spam information
X-SpamDetect: **********: 10.400001 From3consonants=0.3, SPF Soft=3.0,
Symbol & DodgySrc=2.0, DodgySource=2.0, SPF Default Fail=2.5, X-Verify-SMTP
present=0.6
X-SpamDetect-Info: ------------- End ASpam results -----------------

Jaysen Roper wrote:
> I installed the elf toolchain from codesourcery, it went on easily enough
> and after sorting out PATH environments it works fine alongside our
original
> gnu install. I can use both toolchains independently.
>
> But the elf-objcopy doesn't work when used with our coff-build (although
it
For my tools which are rtems ones the BFD support for coff is built into the

elf build of objcopy. I suspect the Codesourcery tools are the same. This
looks like a bug in the old compiler and the coff debug information.

$ /opt/rtems-4.9/bin/m68k-rtems4.9-objcopy
     [ snip ]
/opt/rtems-4.9/bin/m68k-rtems4.9-objcopy: supported targets: elf32-m68k
coff-m68k versados ieee a.out-zero-big elf32-l             ittle elf32-big
srec symbolsrec tekhex binary ihex

> 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 need to provide the command line used to build the object file. At a
guess
it looks like the options you used to build the dbug-outbyte.o are wrong.
Please try:

$ m68k-elf-gcc --target-help

and check your compile options.

> So It looks like my libraries are compiled as 68020 (and I cant change
that)
> And the codesourcery tools are hardcoded to  isa-a (coldfire)

I doubt this. I think they will have multilib'ed their tools.

>
> Is there an old coff-objcopy out there I could use? I don't have the means
> to rebuild it though. My version is 2.9.1 (1997)
>

Given the age of the tools you are using it will be difficult.

Regards
Chris
---
coldfire@...              Send a post to the list.
coldfire-join@...        Join the list.
coldfire-digest@...    Join the list in digest mode.
coldfire-leave@...     Leave the list.



---
coldfire@...              Send a post to the list.
coldfire-join@...        Join the list.
coldfire-digest@...    Join the list in digest mode.
coldfire-leave@...     Leave the list.

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

---
coldfire@...              Send a post to the list.
coldfire-join@...        Join the list.
coldfire-digest@...    Join the list in digest mode.
coldfire-leave@...     Leave the list.

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: coldfire-bounce@... [mailto:coldfire-bounce@...] 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

---
coldfire@...              Send a post to the list.
coldfire-join@...        Join the list.
coldfire-digest@...    Join the list in digest mode.
coldfire-leave@...     Leave the list.



---
coldfire@...              Send a post to the list.
coldfire-join@...        Join the list.
coldfire-digest@...    Join the list in digest mode.
coldfire-leave@...     Leave the list.

Oh yes, sorry I forgot that bit. After a short while puzzling over which
library file these system call functions are in, I came to the same
conclusion you did Jaysen. Then I decided none of these functions are
called in the code anywhere (I assume none of your code does either
otherwise you'd have implemented them to make them do something)

Since they aren't really needed I just added some stubs to demo.c say,
like this:

void isatty()
{
}

void sbrk()
{
}

void write()
{
}

..... etc for each missing symbol.

That will sort those linker errors.

Ed Langley

Software Engineer



-----Original Message-----
From: coldfire-bounce@... [mailto:coldfire-bounce@...]
On Behalf Of Jaysen Roper
Sent: 13 August 2008 10:09
To: Edwin Langley
Subject: RE: [ColdFire] objcopy problems

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: coldfire-bounce@... [mailto:coldfire-bounce@...]
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

---
coldfire@...              Send a post to the list.
coldfire-join@...        Join the list.
coldfire-digest@...    Join the list in digest mode.
coldfire-leave@...     Leave the list.



---
coldfire@...              Send a post to the list.
coldfire-join@...        Join the list.
coldfire-digest@...    Join the list in digest mode.
coldfire-leave@...     Leave the list.



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

---
coldfire@...              Send a post to the list.
coldfire-join@...        Join the list.
coldfire-digest@...    Join the list in digest mode.
coldfire-leave@...     Leave the list.

Ed, I think your linker def file is still specifying OUTPUT_FORMAT("coff-m68k") so its not picking up the lib differences in pluto6.a etc..


----------------------

And when I check the differences between "before and after" objcopy conversion I see that some debug info has gone. The resulting code does run on the target, but alas still no source level debug.

The following is (with OUTPUT_FORMAT==COFF in the linker def)



C:\Games\heber\demo>m68k-elf-objdump -x demo.elf

demo.elf:     file format coff-m68k                               <<----- because of the linker def file
demo.elf
architecture: m68k:68020, flags 0x00000136:
EXEC_P, HAS_LINENO, HAS_SYMS, HAS_LOCALS, D_PAGED
start address 0x60000400

m68k-elf-objcopy --debugging -O ieee -R .id -R .system demo.elf demo.695

demo.elf: .stab: stab entry 1 is corrupt, strx = 0x17000000, type = 9
debug_record_line: no current unit
Last stabs entries before error:
n_type n_desc n_value  string
211    0      00000000
3      0      00000000 idram.c
CATCH  0      00000000 idram.c
153    0      00000000 idram.c
SCOPE  0      00000000 idram.c
243    0      00000000 idram.c
29     0      00000000 dram.c
DSLINE 0      00000000 dram.c
SSYM   0      00000000 dram.c
123    0      00000000 dram.c
155    0      00000000 dram.c
175    0      00000000 dram.c
233    0      00000000 dram.c
GSYM   0      18000000 ram.c
NSYMS  0      19000000 ram.c
SLINE  0      1a000000 ram.c

C:\Games\heber\demo>m68k-elf-objdump -x demo.695

demo.695:     file format ieee
demo.695
architecture: m68k:68020, flags 0x00000010:
HAS_SYMS                                                        <<------ Line numbers and local syms have gone after objdump
start address 0x60000400

------------------------------------------


If I specify OUTPUT_FORMAT("elf32-m68k") in the linker def file, then I get what I expected, Pluto libs need rebuilding with --march=xxx switch.



m68k-elf-ld -L/heber/pluto6/libs/peripherals/pluto6/81-16631-11 -L/heber/pluto6/libs/hardware/pluto6/81-16616-22 -L/hebe
r/pluto6/libs/customperipherals/pluto6/81-17315-5 -L/heber/pluto6/libs/interface/pluto6/81-17292-9 -L"C:\Program Files\C
odeSourcery\Sourcery G++ Lite\lib\gcc\m68k-elf\4.2.3\m5206e" -L"C:\Program Files\CodeSourcery\Sourcery G++ Lite\m68k-elf
\lib\m5206e" -Map demo.map -odemo.elf  --script=pluto6.ld game.o config.o devices.o demo.o sysram.o idram.o fpga.o  -lpe
ripherals -lcustomperipherals -linterface -lpluto6  -lg -lc -lgcc -lm -liberty -lstdc++
m68k-elf-ld: failed to merge target specific data of file /heber/pluto6/libs/hardware/pluto6/81-16616-16/vectors.o
m68k-elf-ld: m68k:68020 architecture of input file `/heber/pluto6/libs/peripherals/pluto6/81-16631-11\libperipherals.a(s
tepper.o)' is incompatible with m68k:isa-a:nodiv output
m68k-elf-ld: m68k:68020 architecture of input file `/heber/pluto6/libs/peripherals/pluto6/81-16631-11\libperipherals.a(t
imer.o)' is incompatible with m68k:isa-a:nodiv output
m68k-elf-ld: m68k:68020 architecture of input file `/heber/pluto6/libs/peripherals/pluto6/81-16631-11\libperipherals.a(e
2rom.o)' is incompatible with m68k:isa-a:nodiv output
m68k-elf-ld: m68k:68020 architecture of input file `/heber/pluto6/libs/peripherals/pluto6/81-16631-11\libperipherals.a(s
tepfnc.o)' is incompatible with m68k:isa-a:nodiv output
m68k-elf-ld: m68k:68020 architecture of input file `/heber/pluto6/libs/customperipherals/pluto6/81-17315-5\libcustomperi
pherals.a(rm161680.o)' is incompatible with m68k:isa-a:nodiv output
m68k-elf-ld: m68k:68020 architecture of input file `/heber/pluto6/libs/interface/pluto6/81-17292-9\libinterface.a(audioh
sfdrv.o)' is incompatible with m68k:isa-a:nodiv output
m68k-elf-ld: m68k:68020 architecture of input file `/heber/pluto6/libs/interface/pluto6/81-17292-9\libinterface.a(fat32.
o)' is incompatible with m68k:isa-a:nodiv output
m68k-elf-ld: m68k:68020 architecture of input file `/heber/pluto6/libs/hardware/pluto6/81-16616-22\libpluto6.a(entry.o)'
 is incompatible with m68k:isa-a:nodiv output
m68k-elf-ld: m68k:68020 architecture of input file `/heber/pluto6/libs/hardware/pluto6/81-16616-22\libpluto6.a(wrapper.o
)' is incompatible with m68k:isa-a:nodiv output
m68k-elf-ld: m68k:68020 architecture of input file `/heber/pluto6/libs/hardware/pluto6/81-16616-22\libpluto6.a(fpuart0.o
)' is incompatible with m68k:isa-a:nodiv output
m68k-elf-ld: m68k:68020 architecture of input file `/heber/pluto6/libs/hardware/pluto6/81-16616-22\libpluto6.a(fpuart1.o
)' is incompatible with m68k:isa-a:nodiv output
m68k-elf-ld: m68k:68020 architecture of input file `/heber/pluto6/libs/hardware/pluto6/81-16616-22\libpluto6.a(duart0.o)
' is incompatible with m68k:isa-a:nodiv output
m68k-elf-ld: m68k:68020 architecture of input file `/heber/pluto6/libs/hardware/pluto6/81-16616-22\libpluto6.a(mbusdev.o
)' is incompatible with m68k:isa-a:nodiv output
m68k-elf-ld: m68k:68020 architecture of input file `/heber/pluto6/libs/hardware/pluto6/81-16616-22\libpluto6.a(atadrv.o)
' is incompatible with m68k:isa-a:nodiv output
m68k-elf-ld: m68k:68020 architecture of input file `/heber/pluto6/libs/hardware/pluto6/81-16616-22\libpluto6.a(serialmod
.o)' is incompatible with m68k:isa-a:nodiv output
m68k-elf-ld: m68k:68020 architecture of input file `/heber/pluto6/libs/hardware/pluto6/81-16616-22\libpluto6.a(lamps.o)'
 is incompatible with m68k:isa-a:nodiv output
m68k-elf-ld: m68k:68020 architecture of input file `/heber/pluto6/libs/hardware/pluto6/81-16616-22\libpluto6.a(outputdev
.o)' is incompatible with m68k:isa-a:nodiv output
m68k-elf-ld: m68k:68020 architecture of input file `/heber/pluto6/libs/hardware/pluto6/81-16616-22\libpluto6.a(mxidev.o)
' is incompatible with m68k:isa-a:nodiv output
m68k-elf-ld: m68k:68020 architecture of input file `/heber/pluto6/libs/hardware/pluto6/81-16616-22\libpluto6.a(pic18.o)'
 is incompatible with m68k:isa-a:nodiv output
m68k-elf-ld: m68k:68020 architecture of input file `/heber/pluto6/libs/hardware/pluto6/81-16616-22\libpluto6.a(except.o)
' is incompatible with m68k:isa-a:nodiv output
m68k-elf-ld: m68k:68020 architecture of input file `/heber/pluto6/libs/hardware/pluto6/81-16616-22\libpluto6.a(serialfnc
.o)' is incompatible with m68k:isa-a:nodiv output
m68k-elf-ld: m68k:68020 architecture of input file `/heber/pluto6/libs/hardware/pluto6/81-16616-22\libpluto6.a(vfd1.o)'
is incompatible with m68k:isa-a:nodiv output
m68k-elf-ld: m68k:68020 architecture of input file `/heber/pluto6/libs/hardware/pluto6/81-16616-22\libpluto6.a(devmgr.o)
' is incompatible with m68k:isa-a:nodiv output
m68k-elf-ld: m68k:68020 architecture of input file `/heber/pluto6/libs/hardware/pluto6/81-16616-22\libpluto6.a(dmamod.o)
' is incompatible with m68k:isa-a:nodiv output
m68k-elf-ld: m68k:68020 architecture of input file `/heber/pluto6/libs/hardware/pluto6/81-16616-22\libpluto6.a(main.o)'
is incompatible with m68k:isa-a:nodiv output
m68k-elf-ld: m68k:68020 architecture of input file `/heber/pluto6/libs/hardware/pluto6/81-16616-22\libpluto6.a(fpuart.o)
' is incompatible with m68k:isa-a:nodiv output
m68k-elf-ld: m68k:68020 architecture of input file `/heber/pluto6/libs/hardware/pluto6/81-16616-22\libpluto6.a(calypso32
.o)' is incompatible with m68k:isa-a:nodiv output
m68k-elf-ld: m68k:68020 architecture of input file `/heber/pluto6/libs/hardware/pluto6/81-16616-22\libpluto6.a(duart.o)'
 is incompatible with m68k:isa-a:nodiv output
m68k-elf-ld: m68k:68020 architecture of input file `/heber/pluto6/libs/hardware/pluto6/81-16616-22\libpluto6.a(constant.
o)' is incompatible with m68k:isa-a:nodiv output
m68k-elf-ld: m68k:68020 architecture of input file `/heber/pluto6/libs/hardware/pluto6/81-16616-22\libpluto6.a(timermod.
o)' is incompatible with m68k:isa-a:nodiv output
m68k-elf-ld: m68k:68020 architecture of input file `/heber/pluto6/libs/hardware/pluto6/81-16616-22\libpluto6.a(pluto6.o)
' is incompatible with m68k:isa-a:nodiv output
cs-make: *** [demo.elf] Error 1

---------------------------------------

I downloaded codesourcery this week, and the libs today from the heber site.

lhdw=   /heber/pluto6/libs/hardware/$(target)/81-16616-22
lper=   /heber/pluto6/libs/peripherals/$(target)/81-16631-11
lcper=  /heber/pluto6/libs/customperipherals/$(target)/81-17315-5
lint=   /heber/pluto6/libs/interface/$(target)/81-17292-9

ihdw=   /heber/pluto6/libs/hardware/$(target)/81-16616-22
iper=   /heber/pluto6/libs/peripherals/$(target)/81-16631-11
icper=  /heber/pluto6/libs/customperipherals/$(target)/81-17315-5
iint=   /heber/pluto6/libs/interface/$(target)/81-17292-9


m68k-elf-gcc ver. 4.2.3
m68k-elf-ld  ver. 2.18.50.20080215
m68k-elf-objcopy ver. 2.18.50.20080215

all from Sourcery G++ Lite 4.2-125


----

Is this getting big? Should we move to email?

Jayse
















-----Original Message-----
From: coldfire-bounce@... [mailto:coldfire-bounce@...] On Behalf Of Edwin Langley
Sent: 13 August 2008 11:29
To: Jaysen Roper
Subject: RE: [ColdFire] objcopy problems

Oh yes, sorry I forgot that bit. After a short while puzzling over which
library file these system call functions are in, I came to the same
conclusion you did Jaysen. Then I decided none of these functions are
called in the code anywhere (I assume none of your code does either
otherwise you'd have implemented them to make them do something)

Since they aren't really needed I just added some stubs to demo.c say,
like this:

void isatty()
{
}

void sbrk()
{
}

void write()
{
}

..... etc for each missing symbol.

That will sort those linker errors.

Ed Langley

Software Engineer

 

-----Original Message-----
From: coldfire-bounce@... [mailto:coldfire-bounce@...]
On Behalf Of Jaysen Roper
Sent: 13 August 2008 10:09
To: Edwin Langley
Subject: RE: [ColdFire] objcopy problems

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: coldfire-bounce@... [mailto:coldfire-bounce@...]
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

---
coldfire@...              Send a post to the list.
coldfire-join@...        Join the list.
coldfire-digest@...    Join the list in digest mode.
coldfire-leave@...     Leave the list.



---
coldfire@...              Send a post to the list.
coldfire-join@...        Join the list.
coldfire-digest@...    Join the list in digest mode.
coldfire-leave@...     Leave the list.



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

---
coldfire@...              Send a post to the list.
coldfire-join@...        Join the list.
coldfire-digest@...    Join the list in digest mode.
coldfire-leave@...     Leave the list.



---
coldfire@...              Send a post to the list.
coldfire-join@...        Join the list.
coldfire-digest@...    Join the list in digest mode.
coldfire-leave@...     Leave the list.