From: Martin Galvan <martin.galvan@tallertechnologies.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH] Python API: Add gdb.is_in_prologue and gdb.is_in_epilogue.
Date: Wed, 22 Oct 2014 17:33:00 -0000 [thread overview]
Message-ID: <CAOKbPbYowBgw3_cpApgF6WH2iUenZcqfUSsvNo+h_JreNu71LA@mail.gmail.com> (raw)
In-Reply-To: <83tx2w87j0.fsf@gnu.org>
On Wed, Oct 22, 2014 at 12:10 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Martin Galvan <martin.galvan@tallertechnologies.com>
>> Cc: Martin Galvan <martin.galvan@tallertechnologies.com>
>> +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.
I looked at this again and I think it should stay as an optional
argument. GDB's in_prologue will only check for the functionStart
argument when it has no other way to determine whether the given PC
belongs to a prologue; otherwise it'll just ignore it. Because of
this, is_in_prologue will return True if we pass it a pc that belongs
to a prologue together with any valid address regardless of it being a
function start, let alone the function PC belongs to. Making it a
required argument to me sounds like we're asking is_in_prologue
whether PC is in the prologue of the function starting at
functionStart, instead of simply telling whether PC belongs to any
prologue (which was my original intent).
I thought of removing the functionStart argument altogether, however
if we're working without debugging info but we're certain of where the
function starts we can still get an accurate result instead of a false
positive. Let me know what you think of this so I can send v2 (I'll
also include a few minor corrections such as correctly casting
gdbpy_is_in_prologue to PyCFunction in the method table).
--
Martín Galván
Software Engineer
Taller Technologies Argentina
San Lorenzo 47, 3rd Floor, Office 5
Córdoba, Argentina
Phone: 54 351 4217888 / +54 351 4218211
next prev parent reply other threads:[~2014-10-22 17:33 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
2014-10-22 15:14 ` Martin Galvan
2014-10-22 17:33 ` Martin Galvan [this message]
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=CAOKbPbYowBgw3_cpApgF6WH2iUenZcqfUSsvNo+h_JreNu71LA@mail.gmail.com \
--to=martin.galvan@tallertechnologies.com \
--cc=eliz@gnu.org \
--cc=gdb-patches@sourceware.org \
/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