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' <lab...@google.com>
Cc: lldb-dev@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:lab...@google.com]
Sent: Thursday, 13 July, 2017 2:37 PM
To: Tatyana Krasnukha <tatyana.krasnu...@synopsys.com>
Cc: lldb-dev@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@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:lab...@google.com]
> Sent: Thursday, 13 July, 2017 2:16 PM
> To: Tatyana Krasnukha <tatyana.krasnu...@synopsys.com>
> Cc: lldb-dev@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@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@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@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=
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Reply via email to