Re: [PATCH] Python API: Add gdb.is_in_prologue and gdb.is_in_epilogue.

[Pedro Alves <palves at redhat dot com>]

On 10/24/2014 08:49 PM, Martin Galvan wrote:
> 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.

That concern with about clients of the Python API, and if another
optional parameter is added to the Python API.

> 
>> 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.

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?

Thanks,
Pedro Alves