VC8-compatible debugging in the works!

Michael Urman mu at tortall.net
Tue Mar 21 05:43:41 PST 2006


On Tue, Mar 21, 2006 at 12:56:05AM -0800, Peter Johnson wrote:
> Obviously the basic mechanism would be something along the lines of a 
> [DEBUG] directive, but I'm looking at the parameters of said directive 
> (label to hook it into the code, plus some flags?), or even multiple 
> directives?  And of course there's the age-old question: would these 
> directives and parameters be debugging-format specific (advantage to 
> getting fuller access to all features of a particular debug format), or a 
> common set (advantage to porting same code to different debug formats). 
> Maybe a combination of both?  Discussion welcome.

To answer this I think we need to figure out what information can be
represented in all formats, what can be represented only in some
formats, and what is actually useful for an assembly programmer.  Once
we do that the decision should be relatively obvious.

Things that seem likely to be useful to specify are:
 * variable types - is this dd an integer or a pointer; if a pointer, what
   does it point to?
 * parameters to and local variables of a function
 * calling convention of a function
 * whether this code be stepped into - possibly most useful for macros if
   that's not already implied by other means like the linemgr.
 * ...

The use cases for all of the above are to try to make a C debugger more
capable of showing the sorts of information they can show for a C
program.  Being able to show variables is paramount.  Being able to show
callstacks would be great to have.  Being able to avoid useless stepping
when not explicitly requested by a breakpoint would be nice.

What of these and other useful items are representable in the supported
debug formats?  They should give us a decent cross section of what
support we can expect, so it would be reasonable to discard information
(with warning) in debug formats without such capabilities if we come
across them later.

Michael
-- 
Michael Urman  [- mu at tortall.net -]


More information about the yasm-devel mailing list