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 behavi
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
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.
Thanks,
Tatyana
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
Hi,
I need an ability to skip some registers when lldb restores register state
after a function call. Didn't find something like gdb "save-restore" register
property. Is there any way to avoid restoring of some registers beside
hardcoding its names in GDBRemoteRegisterContext::WriteAllRegisterVa
