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

[Martin Galvan <martin dot galvan at tallertechnologies dot 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