Re: debuggers

henry@zoo.toronto.edu (Henry Spencer)
Sun, 14 Nov 1993 22:20:04 GMT

          From comp.compilers

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)
| List of all articles for this month |

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
--


Post a followup to this message

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