Related articles |
---|
[5 earlier articles] |
Re: debuggers zstern@adobe.com (1993-11-11) |
Re: debuggers shyamal@seas.smu.edu (1993-11-11) |
Re: debuggers wjw@eb.ele.tue.nl (1993-11-11) |
debuggers ssimmons@convex.com (1993-11-11) |
Re: debuggers sommerfeld@apollo.hp.com (1993-11-11) |
Re: debuggers sean@PICARD.TAMU.EDU (1993-11-12) |
Re: debuggers henry@zoo.toronto.edu (1993-11-14) |
Re: debuggers zstern@adobe.com (1993-11-15) |
Newsgroups: | comp.compilers |
From: | henry@zoo.toronto.edu (Henry Spencer) |
Keywords: | debug |
Organization: | U of Toronto Zoology |
References: | 93-11-075 |
Date: | Sun, 14 Nov 1993 22:20:04 GMT |
sean@PICARD.TAMU.EDU (buzzard) writes:
>If a compiler actually wants to directly support it, every memory write
>could be made a function call, with the obvious cost in performance, or
>every memory write could have a nop (or multiple nops as necessary) after
>it which the debugger can backpatch with the same function call...
There's a fundamental problem, alas, with any scheme in which the compiler
is asked to generate different code to assist debugging. What do you do
about libraries? You end up having to maintain multiple versions of the
major libraries, with and without debugging enabled, which is a practical
nightmare. If you need code transformations, for whatever purpose --
debugging, profiling, etc. -- it's much better to have them done by
postprocessing the binary. This is harder, but it has the enormous
advantage that it's applicable to all code, even if recompilation is
impractical (libraries) or impossible (no sources).
--
Henry Spencer @ U of Toronto Zoology, henry@zoo.toronto.edu utzoo!henry
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.