Re: [PING][RFC][PATCH v2] Python API: add gdb.stack_may_be_invalid

[Martin Galvan <martin dot galvan at tallertechnologies dot com>]

On Fri, Nov 7, 2014 at 2:09 PM, Pedro Alves <palves@redhat.com> wrote:
> On 11/07/2014 01:32 PM, Martin Galvan wrote:
>> 2) The behavior of handle_step_into_function and setting breakpoints
>> is inconsistent for optimized code, at least in ARM. If you step into
>> a function in a program compiled with gcc -O1, you'll see the PC ends
>> up one instruction after the set of instructions that place the
>> arguments passed as registers in the registers they'll be used in. If
>> you do "break myFunction", however, the breakpoint will correctly be
>> placed at the very first instruction. Both handle_step.. and setting
>> breakpoints have the same effect on -O0 code.
>
> We should really fix this.  I can't imagine we do this on purpose.

Indeed we should. I'll gladly fix this myself once we're done with this patch.

>> If we look at how "break myFunction" works, we'll see that we end up
>> calling find_function_start_sal to determine at which PC we have to
>> place our breakpoint. Therefore, that's the function we should be
>> calling when checking whether the stack frame will be valid at a
>> prologue, as it also accounts for optimizations.
>
> We expose functions and sals as python objects.
> Shouldn't we instead consider exposing find_function_start_sal
> in the function object?  Or maybe symbol_to_sal in the Symbol object?
> I can well imagine these being useful to other use cases.

We could do so, but for this use case we'd still need a way to check
if the stack has been destroyed by e.g. an epilogue.

If we want to make the API as primitive as possible, we could again
expose two functions instead of one (as in my previous patch).

-- 

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