This is the mail archive of the crossgcc@cygnus.com mailing list for the crossgcc project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
> 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!