Path: utzoo!utgpu!water!watmath!clyde!gwu
From: gwu@clyde.ATT.COM (George Wu)
Newsgroups: comp.arch
Subject: Re: debugging on a VLIW machine
Keywords: debuggers
Message-ID: <25412@clyde.ATT.COM>
Date: 26 Apr 88 21:40:20 GMT
References: <8860@sol.ARPA>
Reply-To: gwu@clyde.UUCP (George Wu)
Organization: AT&T Bell Laboratories, Whippany NJ
Lines: 52

In article <8860@sol.ARPA> bukys@cs.rochester.edu (Liudvikas Bukys) writes:
>I'm curious... to run a debugger on a Multiflow Trace, and make any sense
>out of what you see, I suppose that you have to compile it with trace
>scheduling and other hairy optimizations off?  Is this true?
>
>(I suppose one could automatically intersperse debugger code between
>every line of source code, and have the trace scheduler intertwine it
>so that a source level debugger could still be made to work.  Is this done?)


     Being an expert on neither the Multiflow machine nor debuggers, this
is really more conjecture than fact, but anyways: I'd be suprised to see
debugging code stirred into user code by a compiler. My guess: for each
line of source code, the compiler stores into a table the address of the
first and last instruction it generates (or maybe just the first, since
that's all it really needs). The debugger can then use this to map the PC
to a line of source code.

     In order to set breakpoints, the debugger writes an instruction which
will cause a trap to the debugger into the appropriate location of the
instruction space. (NOTE: I've actually seen this done on a single-user,
MC68000 board. BUT, it won't work quite so easily on a multiuser system
where multiple processes may share the same instruction segment. Copy
on write? Nah, can't be. Maybe your original idea is right: one trap 
inserted by the compiler into the object/assembly for each source to object
map entry. I dunno.) The overwritten instruction will, of course,
eventually have to be restored.

     As for source level execution traces, before each line of source
code is executed, determine what will be the address of the next line
to be executed and write a trap there. Gets kinda tricky for loops,
conditionals, and such. Might be easier to write a trap to all locations
where execution might next go, rather than trying to predict exactly
where to go. And of course, if the compiler does indeed insert it's own
traps into the object code, traces are simple.

     One needs to delineate the two methods here, call them "static" and
"dynamic" debuggers. A static debugger is where the compiler insperses
it's own code, which implies that for this object, you are *always*
debugging. (Unless you can mask this particular interrupt. Or use a null
debugging routine and have the debugger load a new non-null routine, ie.
itself.) The dynamic method means you have to load you debugger and object.

     This seems more like an OS question to me, but I find it interesting,
and would like to see followups by some gurus. Any takers, or perhaps I
should move to comp.unix.wizards?

-- 
					George J Wu

UUCP: {ihnp4,ulysses,cbosgd,allegra}!clyde!gwu
ARPA: gwu%clyde.att.com@rutgers.edu or gwu@faraday.ece.cmu.edu