Skipping registers when restore register state after a function call


I need an ability to skip some registers when lldb restores register state after a function call. Didn’t find something like gdb “” register property. Is there any way to avoid restoring of some registers beside hardcoding its names in GDBRemoteRegisterContext::WriteAllRegisterValues like it is done for arm debugserver?

Thanks for any suggestions,


I'm not sure there is a good way to do that currently.

However, if you tell us what is the higher level problem you are
trying to solve, we may be able to provide an alternative (right now,
the only reason I can think of why you would *not* want to
save/restore all registers is the orig_rax pseudo-register, for which
we do have a solution)

I'm porting lldb to baremetal ARC target and now I try to call functions from expressions. It works well until ThreadPlanCallFunction tries to restore register state. In that moment my gdb-server crashes because of attempt to write some registers that shouldn't be written.


Aha, I see. I take it these are some registers which provide the state
of the cpu, but are not modifiable by user code. Presumably the same
crash would happen if the user manually issued a "register write"
command (?)

The fact that the stub crashes after this command sounds like a bug in
the stub for me. However, even if it is fixed to return error, the
register save-restore machinery might get confused by the fact that
the register write failed. Maybe we could try adding a read-only field
to the register info struct to let the machinery know it should not
touch this register?

Yes, you are right about bug in the stub, and that returning of an error will not solve the problem. I like the idea to add a field to register info. But I doubt that "read-only" may confuse someone, because such registers are not really read-only - just its modifying leads to undesirable behavior.


Trying to add new field to RegisterInfo I ran into the problem that it requires modifying all hardcoded register infos (for each target's ABI and RegisterContext), despite almost all targets never need this field. Another decision is to add a set with such register names into DynamicRegisterInfo and skip restoring of a register if it exists in this set. This solution works for me as needed and it seems less invasive in terms of other targets. I can prepare a patch if you'll consider it useful.


We've ran into the same issue when we were adding the "dynamic
register size" fields, which is mips thing. I think we need a more
flexible way of specifying the register context structs (constexpr
constructors?) which will not suffer from these issues.