How do I do source code correlation with a dis-assembler?

How do I do source code correlation with a dis-assembler?

The basic process for supporting source code correlation is as follows:
The user compiles their code, using a compiler switch to tell the compiler to include debug or symbolic information in the object file.
At this point, the debug information is still incomplete, and is in a re-locatable format that we can't use. Multiple such object files are then linked together to form an executable image file. In many cases, it is also necessary to specify a switch to the linker to tell it to take the debug information from the object files and pass it along to the executable image. The linker is responsible for competing the debug information that was generated by the compiler. It must convert the relocatable information into absolute locations. This means that the user must tell the linker exactly where in memory the executable image is to load and run. Once this is done, then we can extract the debug information from the executable file using file readers for various file formats built into the TLA application.

There is one caveat to watch out for here. The executable image must be in "absolute" format. In other words, it can't be left in relocatable format. If it is, then we can't use it. If the user plans to load their executable into ROM, then it will typically be in absolute format, but if they are going to be loading it into some RTOS, from a disk for example, then it may not be. Many RTOS's perform the final link stage at run-time, so they can locate the program at whatever memory location happens to be available at the time. In order to do this, they must leave the executable image in relocatable format, which we can't use.

Assuming that the user is planning to generate an "absolute" file, then the only issue that remains is whether or not we can read that file. A while back we did some testing with three different Ada compilers. One from DDCI that didn't work at all and two others from ESS-Scicon and Tartan, with which we had acceptable, but not perfect results. This happens because compiler vendors are making subtle changes to their object file formats all the time. We've also made some significant improvements in our file readers since then, so those old results can serve as a hint, but won't really tell you anything definitive.

The only way to be sure if we can support a specific compiler vendor's tools is to try reading their object file with our file readers. We have a stand-alone version of our file readers that you can give to the customer if they want to try this out when evaluating different tool vendors. It's called tlasym, and basically, it just reads in the customer's object file, and outputs an ASCII file in our own proprietary format called TSF. This latter file is easily human readable and can be examined by the customer to see if it looks like we read their object file correctly. Tlasym uses exactly the same file readers as are built into the TLA application, so if it reads the file, then it's safe to assume that the TLA application will do so.

One final caveat to consider is that our ability to do source code correlation is only as good as the quality of debug information that the compiler puts in the object files. If the compiler vendor puts in lots of detail, then we can correlate down to the level of individual statements on a multi-statement line, but if the compiler is sloppy, then results can be much less satisfying. The only real way to be sure is to use the compiler to generate some sample executables, run them, and do an acquisition to test the correlation.