Re: [PATCH] Infer $pc in a file's trace frame

[Eli Zaretskii <eliz@gnu.org>]

> Date: Thu, 01 Apr 2010 15:15:24 -0700
> From: Stan Shebs <stan@codesourcery.com>
> 
> This patch is a small usability enhancement from trace frames coming 
> from a trace file; if registers have not been collected, then clear them 
> all, and guess that $pc must be the same as the tracepoint's address.  
> This isn't a good idea for either multi-location tracepoints or stepping 
> frames though, and we want to warn the user about those cases.

Thanks.

> + @item
> + If you do not collect registers at a tracepoint, @value{GDBN} can
> + infer that the value of the PC is the address of the tracepoint and
> + display that when you are looking at a trace frame for that
> + tracepoint.  However, this cannot work if the tracepoint has multiple
> + locations (for instance if it was set in a function that was inlined),
> + or if it has a @code{while-stepping} loop.  In those cases
> + @value{GDBN} will warn you that it can't infer the PC, and default it
> + to zero.  Also, @code{tdump} will use the list of collections for the
> + tracepoint proper, and not its stepping list, although the values
> + displayed will be correct for the stepping frame.  Explicit print
> + commands will always work correctly.

This is okay, but the last two sentences leave so much stuff
unexplained that I doubt the reader will be able to understand their
meaning, unless she is a tracepoint hacker.  At the very least, I
think you should:

  . add cross-references to where `tdump' and `while-stepping' are
    described

  . use the same terminology as you do there, and if the terminology
    is not explained there  ("stepping list"? what's that?), introduce
    it in those places

  . add an example to show the issues you are describing.

Btw, the description of `tdump' has nothing to say about any special
behavior in the presence of `while-stepping', whereas the above seems
to hint that there's something we should say about that.