[lldb-dev] Skipping registers when restore register state after a function call

[Tatyana Krasnukha via lldb-dev]

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.

Thanks,
Tatyana

-----Original Message-----
From: Tatyana Krasnukha 
Sent: Thursday, 13 July, 2017 3:01 PM
To: 'Pavel Labath' <labath at google.com>
Cc: lldb-dev at lists.llvm.org
Subject: RE: [lldb-dev] Skipping registers when restore register state after a function call

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.

Thanks,
Tatyana

-----Original Message-----
From: Pavel Labath [mailto:labath at google.com]
Sent: Thursday, 13 July, 2017 2:37 PM
To: Tatyana Krasnukha <Tatyana.Krasnukha at synopsys.com>
Cc: lldb-dev at lists.llvm.org
Subject: Re: [lldb-dev] Skipping registers when restore register state after a function call

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?

On 13 July 2017 at 12:26, Tatyana Krasnukha via lldb-dev <lldb-dev at lists.llvm.org> wrote:
> 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
>
> -----Original Message-----
> From: Pavel Labath [mailto:labath at google.com]
> Sent: Thursday, 13 July, 2017 2:16 PM
> To: Tatyana Krasnukha <Tatyana.Krasnukha at synopsys.com>
> Cc: lldb-dev at lists.llvm.org
> Subject: Re: [lldb-dev] Skipping registers when restore register state 
> after a function call
>
> 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)
>
> On 13 July 2017 at 12:06, Tatyana Krasnukha via lldb-dev <lldb-dev at lists.llvm.org> wrote:
>> 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::WriteAllRegisterValues like it is done for 
>> arm debugserver?
>>
>>
>>
>> Thanks for any suggestions,
>>
>> Tatyana
>>
>>
>> _______________________________________________
>> lldb-dev mailing list
>> lldb-dev at lists.llvm.org
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cg
>> i
>> -2Dbin_mailman_listinfo_lldb-2Ddev&d=DwIFaQ&c=DPL6_X_6JkXFx7AXWqB0tg&
>> r
>> =yfnu24japkhNGh-WqJObHXmH3mINtC_2FO828lrNpM0&m=xQwSXvPwlPz8CJ0HNdZzGQ
>> K
>> bqJgS9_gurfUe7UBAJc4&s=wHAU8LK6EtYfrxcSHTTJDCUlZ9yxQW72oPMlQK9KJSU&e=
>>
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi
> -2Dbin_mailman_listinfo_lldb-2Ddev&d=DwIFaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r
> =yfnu24japkhNGh-WqJObHXmH3mINtC_2FO828lrNpM0&m=X2B3EThXxPLbgM5Du4XBwo2
> Oby1TAS_qzsSn19dGNU8&s=bg2WaOthZ_IMN1zNqRVjDVoz3hbHOrfKkc5oVe_SFI4&e=