This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] Python API: Add gdb.is_in_prologue and gdb.is_in_epilogue.
- From: Pedro Alves <palves at redhat dot com>
- To: Martin Galvan <martin dot galvan at tallertechnologies dot com>
- Cc: gdb-patches at sourceware dot org, Doug Evans <dje at google dot com>, Eli Zaretskii <eliz at gnu dot org>, Ulrich Weigand <uweigand at de dot ibm dot com>, Daniel Gutson <daniel dot gutson at tallertechnologies dot com>
- Date: Fri, 24 Oct 2014 23:34:09 +0100
- Subject: Re: [PATCH] Python API: Add gdb.is_in_prologue and gdb.is_in_epilogue.
- Authentication-results: sourceware.org; auth=none
- References: <1413986485-4673-1-git-send-email-martin dot galvan at tallertechnologies dot com> <544822D6 dot 8020606 at redhat dot com> <544828BB dot 9040900 at redhat dot com> <CAOKbPbZJfQYmGk9PyQ2C7Y-hat-KxfvR-pC4sNHpF4_zdarRfQ at mail dot gmail dot com> <544A68B1 dot 9000909 at redhat dot com> <CAOKbPbZN3k=gdLkLdGp4cj9MFfiBOAneTeo6WaHD5PoFv7Rx8g at mail dot gmail dot com> <544AB1E5 dot 8030509 at redhat dot com> <CAOKbPbZ7vBbG50eYw3ehNzp7SyOw9Sgo1S-CFdYpfJT6Xo6=1Q at mail dot gmail dot 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