Re: Simple Debugger Design

John wrote:
>
> [The hard parts are tracking what object code corresponds to
> what source code, particularly after optimization that
> rearrangs the code,


Hmm... I don't think this is done in assemblers. But it's still an
issues: assembly code usually makes heavy use of macros, and it will
indeed be a challenge to preserve enough information to reconstruct
the original source.


> and keeping enough info to prettyprint data structures. -John]


That's a real issue for assemblers, yes (there are typically many ways
to represent binary data in an assembly language, e.g. strings may be
represented as byte values or character sequences).




Actually the easiest and most reliable way is to just store the full
source in the binary (maybe after stripping irrelevant parts). With
today's disk drive capacities, this isn't usually a problem.
I'm using a compiler that does this on a routine basis for debug builds.
It wants to present the exact source code as of compilation time during
debugging (and this *is* a form of reverse compilation), and it works
like a charm. (Well, debug executables are roughly five time the size of
production builds, but this is both due to the inclusion of source code
and to the generation of extensive checking code.)


Regards,
Joachim

Return to the comp.compilers page.
Search the comp.compilers archives again.