Re: GDB call and p func() on embedded target

[Simon Marchi <simon.marchi@polymtl.ca>]

On 2021-08-18 4:31 p.m., Maximilian Schneider wrote:
> Thank you for the great information!
> 
> Turns out it was the start address. Since gdb is setting up a frame to
> call my function and then return to the start address; it is no wonder
> that it does not work. 0 is neither ram not flash so sw breakpoints
> will not work there. HW breakpoints probably won't work there either.
> 
> I added -e 0x2000000 to the compilation to set an explicit entry point
> and huzza it works :)

Ok, good news!

> If gdb is already putting code on the stack to call my function why not
> implement a sw breakpoint there? Why return to start?
> 
> Why does gdb care at all what the start address is? Since this is an
> external loader that lives in ram and has no main() i don't see what
> the point of the entry point is.

GDB just needs a place it can put a breakpoint and redirect execution
to, to get back control when the inferior function call is done.  It
just happens that the entry point usually works fine for that, at least
when you are talking about a program that runs on an OS like Linux.  I
guess it just doesn't work in all cases, such as yours.

As we saw, other architectures do use the stack for this, they have
gdbarch_call_dummy_location return ON_STACK and implement
gdbarch_push_dummy_code.  I suppose you would have to make the ARM
architecture do that to make it work properly in your case.

Simon