Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Martin Galvan <martin.galvan@tallertechnologies.com>
Cc: gdb-patches@sourceware.org, martin.galvan@tallertechnologies.com
Subject: Re: [PATCH] Python API: Add gdb.is_in_prologue and gdb.is_in_epilogue.
Date: Wed, 22 Oct 2014 15:10:00 -0000	[thread overview]
Message-ID: <83tx2w87j0.fsf@gnu.org> (raw)
In-Reply-To: <1413986485-4673-1-git-send-email-martin.galvan@tallertechnologies.com>

> From: Martin Galvan <martin.galvan@tallertechnologies.com>
> Cc: Martin Galvan <martin.galvan@tallertechnologies.com>
> Date: Wed, 22 Oct 2014 11:01:25 -0300
> 
> Added two new functions to the Python API: gdb.is_in_prologue and gdb.is_in_epilogue.

Thanks.

>     * NEWS: Mention new Python functions.

This part is OK.

> +@findex gdb.is_in_prologue
> +@defun gdb.is_in_prologue (pc, @r{[}functionStart@r{]})
> +Returns @code{True} if the given @var{pc} value *might* correspond to

Please use Texinfo markup for emphasis, not ASCII art.  I think you
want @emph{might} here.

> +The optional @var{functionStart} argument is the start address of the
> +function you want to check if @var{pc} belongs to.  If your binary
                              ^^
"whether"

> +doesn't have debugging info, @value{GDBN} may need to use this value
> +to guess if @var{pc} belongs to the prologue.  If omitted it defaults
            ^^
Likewise.

> +In general you shouldn't worry about passing a @var{functionStart}
> +argument unless your binary doesn't have debugging info, in which case
> +ommiting @var{functionStart} may result in @code{True} being returned
> +when the @var{pc} is not actually inside a prologue.

Isn't it better to require this argument in that case?  Zero is not
very useful starting address, in most cases.

> +When stepping by machine instructions it's possible that local variables
> +appear to have wrong values at the end of a function.  This happens
> +because it usually takes more than one instruction to tear down a stack
> +frame; such instructions are part of a function's epilogue.  @value{GDBN}
> +can identify the addresses where the local variables may show wrong
> +values and inform you so.

This repeats almost verbatim what has been already said about the
prologue.  It would be better to make a single description that covers
both the prologue and the epilogue, before you describe the 2 methods.

OK with those changes.


  reply	other threads:[~2014-10-22 15:10 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-22 14:02 Martin Galvan
2014-10-22 15:10 ` Eli Zaretskii [this message]
2014-10-22 15:14   ` Martin Galvan
2014-10-22 17:33   ` Martin Galvan
2014-10-22 17:47     ` Eli Zaretskii
2014-10-22 18:06       ` Martin Galvan
2014-10-22 18:07       ` Eli Zaretskii
2014-10-22 18:32         ` Martin Galvan
2014-10-22 18:37           ` Eli Zaretskii
2014-10-22 19:23 ` Doug Evans
2014-10-22 21:34 ` Pedro Alves
2014-10-22 21:59   ` Pedro Alves
2014-10-23 17:36     ` Martin Galvan
2014-10-23 17:57       ` Ulrich Weigand
2014-10-23 18:09         ` Martin Galvan
2014-10-23 18:14           ` Daniel Gutson
2014-10-24  2:42             ` Doug Evans
2014-10-24 14:58         ` Pedro Alves
2014-10-24  4:57       ` Doug Evans
2014-10-24 15:02         ` Pedro Alves
2014-10-24 15:34           ` Ulrich Weigand
2014-10-24 15:47             ` Doug Evans
2014-10-24 14:57       ` Pedro Alves
2014-10-24 15:13         ` Ulrich Weigand
2014-11-07 14:45           ` [push] Revert old nexti prologue check and eliminate in_prologue Pedro Alves
2014-10-24 19:49         ` [PATCH] Python API: Add gdb.is_in_prologue and gdb.is_in_epilogue Martin Galvan
2014-10-24 20:09           ` Pedro Alves
2014-10-24 21:11             ` Martin Galvan
2014-10-24 22:34               ` Pedro Alves
2014-10-27 16:40                 ` Martin Galvan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83tx2w87j0.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=gdb-patches@sourceware.org \
    --cc=martin.galvan@tallertechnologies.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox