Problems with m68k-coff-ld
Josef Wolf
jw@raven.inka.de
Mon Sep 8 16:25:00 GMT 1997
> 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?
> 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?
> > - 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!
More information about the crossgcc
mailing list