From: Martin Galvan <martin.galvan@tallertechnologies.com>
To: Pedro Alves <palves@redhat.com>
Cc: gdb-patches@sourceware.org, Doug Evans <dje@google.com>,
Eli Zaretskii <eliz@gnu.org>,
Ulrich Weigand <uweigand@de.ibm.com>,
Daniel Gutson <daniel.gutson@tallertechnologies.com>
Subject: Re: [PATCH] Python API: Add gdb.is_in_prologue and gdb.is_in_epilogue.
Date: Fri, 24 Oct 2014 19:49:00 -0000 [thread overview]
Message-ID: <CAOKbPbZN3k=gdLkLdGp4cj9MFfiBOAneTeo6WaHD5PoFv7Rx8g@mail.gmail.com> (raw)
In-Reply-To: <544A68B1.9000909@redhat.com>
On Fri, Oct 24, 2014 at 11:56 AM, Pedro Alves <palves@redhat.com> wrote:
> On 10/23/2014 06:36 PM, Martin Galvan wrote:
>>> > Some targets have code at address 0. Seems like we may be exposing a
>>> > bad interface for these targets here?
>> I used 0 because in_prologue expects it to be non-zero. If it's 0 and
>> we have no debugging info, it'll always return true:
>>
>> /* We don't even have minsym information, so fall back to using
>> func_start, if given. */
>> if (! func_start)
>> return 1; /* We *might* be in a prologue. */
>
> Design mistakes in the internal APIs shouldn't be exposed to a public
> API. I'd even suggest that whatever Python API we end up with, it'd
> be good to make the internal API match it.
>
>>
>> Again, I did it because of the way in_prologue works, but as Eli said
>> this would probably be better handled with a Python exception or a
>> message of some kind.
>
> Not sure an exception makes sense given the function's
> interface. Say in the future another optional parameter is added.
> What would you do then? What of old code that passed in func_start
> but not that new argument? Those might not expect an exception.
> So for the case of the new argument not being specified, we'd
> have to return 1, which is right -- the PC _might_ be pointing
> at a prologue.
I probably didn't make myself clear-- I wasn't talking about using
in_prologue directly anymore, but to follow its approach in the API
function. Of course it wouldn't make sense to put Python exception
raising directly inside in_prologue.
> But, how exactly were you planning using the gdb.is_in_prologue
> function? GDB itself doesn't use this to determine whether locals
> are valid, only gdbarch_in_function_epilogue_p/gdb.is_in_epilogue.
Well, I followed the code while testing a rather simple function and
noticed that handle_step_into_function is very similar (in terms of
the approach) to in_prologue plus some address corrections and setting
a breakpoint to proceed to. The API function needs only the address
calculation part.
What if:
1) I split handle_step_into_function in the address calc part and
the brakpoint insertion part,
moving the address calc to a new function (publicly available from infrun.h).
2) I expose such function to the Python API.
Would that be accepted? Would you want to see a patch?
Please keep in mind that what I actually need is not really messing
with the prologue, but to know where the local variables are
accessible. If I could simply use DWARF info to accomplish that then I
wouldn't even touch the prologue at all.
Thanks!
--
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-24 19:49 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
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 ` Martin Galvan [this message]
2014-10-24 20:09 ` [PATCH] Python API: Add gdb.is_in_prologue and gdb.is_in_epilogue 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='CAOKbPbZN3k=gdLkLdGp4cj9MFfiBOAneTeo6WaHD5PoFv7Rx8g@mail.gmail.com' \
--to=martin.galvan@tallertechnologies.com \
--cc=daniel.gutson@tallertechnologies.com \
--cc=dje@google.com \
--cc=eliz@gnu.org \
--cc=gdb-patches@sourceware.org \
--cc=palves@redhat.com \
--cc=uweigand@de.ibm.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).