John Porubek writes: > Hi Daniel, > > It sounds like dealing with IAR's version of an ELF-format file is > turning into more work than is justified. I strongly suspect that the > overwhelming majority of your target audience is using mspgcc. This > *is* the "Mspgcc-users" mailing list, after all! I'll probably be > converting over to mspgcc myself, one of these days. > > As I mentioned previously, I have successfully created a symbol file > that works using "nm". As for programming, I currently do that from > IAR but, if I use MSPDebug, I can use Intel HEX (and lose the > autoloading of symbols that the ELF format provides - not a huge > deal). So, barring anyone else stepping up with the information you > need, I can still limp along (just kidding!) using a few extra steps. > > BTW, while looking for more info. on IAR's ELF format, I found the > following "Known Problem" in the "Release notes for the MSP430 IAR > Embedded Workbench product package version 5.10.1": > > "EW20738: If you select ELF/DWARF as output format from the linker, > only the ELF part with symbol information etc will be generated. The > DWARF part is not provided which means that it is not possible to use > the output file for debugging. The linker does not generate any > warning message about this." > > I don't know if this sheds any useful light on the subject, but there it is. > > Thanks for your efforts, > > --John
Hi John, What I've done for now is changed the machine-type check from an error to a warning. So you'll be able to load symbols directly, but I'm not going to bother trying to do anything special for programming. This change is in the public git repository now, if you want to try it out (http://mspdebug.git.sourceforge.net/). By the way, the DWARF part is more an issue for msp430-gdb users -- it contains high-level debugging information. Cheers, Daniel
