From: Pedro Alves <palves@redhat.com>
To: Martin Galvan <martin.galvan@tallertechnologies.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 22:34:00 -0000 [thread overview]
Message-ID: <544AD3E1.4030003@redhat.com> (raw)
In-Reply-To: <CAOKbPbZ7vBbG50eYw3ehNzp7SyOw9Sgo1S-CFdYpfJT6Xo6=1Q@mail.gmail.com>
On 10/24/2014 10:11 PM, Martin Galvan wrote:
> On Fri, Oct 24, 2014 at 5:09 PM, Pedro Alves <palves@redhat.com> wrote:
>>> 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.
>>
>> Hmm, how is this different from simply doing "break function" ?
>> GDB sets function breakpoints after the prologue already. A "step"
>> into a function should stop at the exact same address as if the user
>> did "b function; c" to run to said function.
>>
>> So, when you detect that you stepped into a function, you could
>> just set the breakpoint by function name?
>
> In order for that to work, I'd have to run the program up to that
> point.
You can set breakpoints before running the program:
(top-gdb) b *main
Breakpoint 3 at 0x45ed30: file /home/pedro/gdb/mygit/build/../src/gdb/gdb.c, line 25.
(top-gdb) b main
Breakpoint 4 at 0x45ed3f: file /home/pedro/gdb/mygit/build/../src/gdb/gdb.c, line 28.
That offset is your "prologue", however meaningful that is.
> I really need to be able to determine if at a given PC the
> local variables will be accessible
Why?
> without actually running the
> program. Ideally I'd use only DWARF info to know that.
I think we still don't know what you're trying to do, only
a bit of _how_ you're trying to do it. :-) It makes it
harder to understand the use case, and to suggest solutions.
> I looked up the approach GDB takes when setting a breakpoint at a
> function name. From what I saw it appears to be similar as the
> "optimistic" path from in_prologue (that is, using symtab and line
> info). I guess that makes sense since setting a breakpoint by function
> name by definition requires us to have debugging info.
If you need access to local variables, then you're already
relying on debug info.
Thanks,
Pedro Alves
next prev parent reply other threads:[~2014-10-24 22:34 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 ` [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 [this message]
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=544AD3E1.4030003@redhat.com \
--to=palves@redhat.com \
--cc=daniel.gutson@tallertechnologies.com \
--cc=dje@google.com \
--cc=eliz@gnu.org \
--cc=gdb-patches@sourceware.org \
--cc=martin.galvan@tallertechnologies.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).