Post by thread:[PIC] On CODs and COFFs

Hello people, I suspect I'm doing something wrong, I'd appreciate suggestions: I'd like to complete my 'home-brew' PIC simulator with a better input from the assembler object files. At first, I put in a parser for the .lst files, which worked fine, but there seem to be subtle differences in assemblers (even different gpasm versions). So I looked at .cod files, and submitted an info request at Bytecraft, without any reply (yet). Just sent a reminder. Next possibility was the .o (COFF file) output. I read that there are utilities that post-convert the .o output to .cod and .hex as needed. But after some work, I found that variables are not included in the COFF file from gpasm (neither from mpasm, it seems). Is there any command line option necessary to enable this? Option -g doesn't seem practical, as variables must be defined manually with .file & family, and automatic symbol inclusion is disabled. Joh

On Mon, Jul 9, 2012 at 1:08 PM, John Coppens <spam_OUTjohnTakeThisOuTjcoppens.com> wrote: > Next possibility was the .o (COFF file) output. I read that there are > utilities that post-convert the .o output to .cod and .hex as needed. > But after some work, I found that variables are not included in the > COFF file from gpasm (neither from mpasm, it seems). 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.) 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. 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. -- Martin K

On Tue, 10 Jul 2012 14:01:21 -0400 "M.L." <.....mKILLspam@spam@lkeng.net> 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... Thanks for the feedback, Martin Joh

John Coppens wrote: {Quote hidden}> On Tue, 10 Jul 2012 14:01:21 -0400 > "M.L." <mKILLspamlkeng.net> 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