Re: [PATCH 1/5] gdb/python: handle saving user registers in a frame unwinder

Andrew Burgess
2021-06-07T16:10:54Z

* Tom Tromey <tom@tromey.com> [2021-06-07 08:50:56 -0600]:

> >>>>> "Andrew" == Andrew Burgess <andrew.burgess@embecosm.com> writes:
>
> Andrew> So, in this patch I propose that in the unwinder code, when
> Andrew> add_saved_register is called, if it is passed a
> Andrew> user-register (i.e. non-cooked) then we first fetch the register,
> Andrew> extract the real register number from the value's location, and use
> Andrew> that new register number when handling the add_saved_register call.
>
> Andrew> If either the value location that we get for the user-register is not
> Andrew> a cooked register then we can throw a 'Bad register' error back to the
> Andrew> Python code, but in most cases this will not happen.
>
> I was worried that requesting this would require unwinding the register,
> which is what is currently being done. But I suppose the idea is that
> the value is normally lazy, so it isn't actually unwound?

You are correct, accessing any register from an unwinder is going to
give us a lazy register value, which we'd expect (in this case) to
have the real register number for $pc, and the frame-id of the next
frame.

When you open with "I was worried that requesting this would require
unwinding the register...", was our concern just that this unwinding
might be expensive? Or are you worried that trying to do that might
break in some way?

Remember, the user can already do:

PendingFrame.read_register('pc')

which is going to fully fetch the register value (so create the same
lazy register value as above, and then make it unlazy), so I don't
think there should be any technical problems here, even if it turns
out that the register value is not lazy.

I guess what I'm saying is, that yes it will be lazy, but I hadn't
really considered that an important part of the system.

Thanks,
Andrew