John Coppens wrote: > On Tue, 10 Jul 2012 14:01:21 -0400 > "M.L." wrote: > > > I can't quote off-hand the COFF but I recall buying a now out of print > > book from Amazon that describes the basic COFF (common object file > > format.) > > Hello Martin, > > COFF documentation isn't a problem - the Microchip C18 compiler manual > has an extensive appendix for the format, with their variants. There > are also several useful pages on COFF at DJ Delorie's site, though they > are for i386 processor. In fact, based on both docs, I already wrote the > COFF parser, and it works well. > > > I'd ignore COD if I was writing a simulator. "Nobody" is going to be > > using it for more than a few years and ELF will be replacing COFF in > > subsequent time periods. > > First off, 'my' simulator is not meant as product... I find writing a > simulator helps me to get to know a particular processor better, and > also it helps teaching my students how to write such tools. > > On the other hand, the COD format has been around for at least 15 years > - it shows, the format is evidently written with a Borland Turbo Pascal > compiler. I agree that it's probably not a very versatile format... > > > Even if you can't get symbol names, there will be a human readable > > symbol table / map (.map file) that you could parse and translate. > > Microchip's mpasm seems to be able to output a cross-reference file, > (*.xrf) but its usefulness seems rather limited. No map. > > gplink -m outputs a map file, but only of program labels... We wrote the COD spec's a long time ago. It has continued to evolve over time. The information in the .COD is a superset of the elf/dwarf file information. Byte Craft has quite a few tools to view and process .COD files. Contact me off line for a copy of the spec and support tools. I agree with the comments that COFF is probably going to disappear to be replaced by elf dwarf. elf dwarf has been evolving as well. Our tools generate a number of different debugging formats including elf dwarf in the current releases. We have found that many of the elf dwarf tools are incompatible primarily in the way they process dwarf information. We are continuing to use .COD because of its support for multiprocessor targets and the ability to communicate with the debugging tools for things like setup information, predefined break points, support for regression testing and embedded print statements that don't generate any application code. Walter Banks Byte Craft Limited --=20 http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist .