Re: Problems with m68k-coff-ld

[Mark Phillips <M.S.Phillips@nortel.co.uk>]

Glad to hear you are making progress!

On Tue, 9 Sep 1997, Josef Wolf wrote:

> > The initialised data appears to works for me, try adding -Wl,-Map,link.map
> > and checking what section your foo variable is being put in. Then check
> > the handling of that section in your startup code.
> 
> I tried the same with coff and it worked well with my startup-code. It
> looks like the ieee format does some strange things to pack and/or
> compress initialized data, so just copying it from ROM to RAM won't work :-(
> 
> Where could I find a description of the ieee-coding-format? Or (even
> better ;-) a piece of code to unpack the ieee-format into the real
> data-section?

I have not come across this problem, when I use XRAY to download it
creates a working image in memory. Are you actually storing the IEEE in
flash or something? We just use objcopy to generate an S record file and
use that for programing any flash/eproms (well actually we generally
download to target RAM and then copy to FLASH, because we used to have
overrun problems when trying to program via an un-flow controlled serial
link:-).

There are docs about the IEEE format on ftp.cygnus.com, I think they are
under the embedded dir (but they might not be!).

> 
> > If you need ieee695 files with debug info, you have probably already
> > discovered it is not possible to directly produce them from the linker. 
> > You will have to compile and link with -g using a different object file
> > format (m68k-coff with the default coff dbg format worked for me). Then
> > run objcopy WITH the --debugging option (this appears to be
> > equivalent to the "try and work flag" :-)).
> 
> Ough! Strange, but it works this way! (at least "strings x.iee|grep '\.c$'"
> gives me what I'd expect. Not tried the debugger yet)
> 
> > I managed to get it mostly working with XRAY (2.3?),
> > but I had to modify the compiler build to put constants in their own
> > section (email me if you need to try this, I have a patch).
> 
> Oups! I have no clue whether I need it because I don't understand this
> sentence :-() Do you mean that XRAY need some magic values in some magic
> sections to work properly? Hmm, I remember something like 'simulated_input',
> 'simulated_output' and 'tags' in the MRI-Compiler with some coments about
> XRAY around them. Maybe this is what you mean?

My version of XRAY appeared to get upset because it saw something like:-

int fred(void)
{
}
const int initialised_var=42;
int bill(void)
{
}

It refused to load the resulting object file, unless I striped debug
symbols.... The error message was something about overlapping sections.  
Not completely sure what was causing the error, but changing the
compiler to put initialised data in a different section (instead of code) 
solved the problem. The problem might have been the type settings on the
text section, but I didn't see the error unless text and initialised data
was interleaved.

I also had problems with other code (ie pSOS) being in sections with silly
type settings (I can't remember if I fixed them with funny objcopy args or
by changing the source).

In case anyone is interested, I have attached my old COFF notes and patches.

The patches do the following:-
binutils - Allows gas to assemble something like
"tst.l a5" on a cpu32 (-mcpu32). I needed this because I changed gcc to
pass -mcpu32 to the assembler and -m68020 -mnobitfields to cc1, and gas
didn't believe the chip could handle the resulting opcode.

Cygnus patch - you know about this one already, in particular gcc v
printf problem etc

lib - Just reduces the number of libs which are built. In particular
the resulting gcc will also reduce the number of libs built by newlib
reducing its build time dramatically - of course you need to use this
from day 1 or do a spring clean to make REAL SURE no one uses an out
of date lib (you no longer build).

coff - Change gcc to pass -mcpu32 to gas and -m68020 -mnobitfields to
cc1 if you use -mcpu32. Also adds some cpp -Ds.

coff2b - Change type info on .ctors and .dtors (to rd from x) and add
.const (rd) section for initialised data.


I am currently using an ELF/DWARF setup, because the SingleStep debugger
from SDS would not read my IEEE files (though XRAY mainly worked, it did
not understand the type info on some structures). I could post my patches
for that, but they would probably not help you because DWARF appears to be
only understood by gcc (not bfd/objcopy) so you can not convert it to
ieee.


> 
> > > - When using the standard-library (newlib) the linker always catches the
> > >   68020-version of the library. This leads to problems with my 68332 :-()
> > >   This problem appears when I use m68k-coff-ld directly as well as when
> > >   I use it through m68k-coff-gcc. The --verbose output seems to be OK, so
> > >   I assume the libraries are not properly built? Here's the output:
> 
> This problem disappeared somehow after a complete recompilation of the
> tool-chain.
> 
> Thank you very much!
> 

Good luck
Mark

68360 coff patches