Re: [PATCH] Fix get ERESTARTSYS with m32 in x86_64 when debug by GDB

Pedro Alves <[email protected]>
Newsgroups gmane.comp.gdb.devel,gmane.linux.kernel
Message-ID <[email protected]>
On 04/30/2014 02:35 PM, Mark Kettenis wrote:
>> Date: Tue, 29 Apr 2014 22:10:15 -0700
>> From: "H. Peter Anvin" <[email protected]>
>>
>> On 04/29/2014 10:08 PM, Andrew Pinski wrote:
>>>
>>> restoring the values is hard since even the ptrace interface does not
>>> allow for that.
>>>
>>
>> So that begs the ultimate question, which is: given the fact that there
>> is *state missing* from the state vector (this is the core of the
>> problem), is there a way we can add that state so that gdb will be able
>> to save and restore it?
> 
> Carrying around additional state in GDB is complicated; I'd rather
> avoid it.

Agreed very much.

> arch/x86/kernel/ptrace.c:putreg32() has this bit of code:
> 
>         case offsetof(struct user32, regs.orig_eax):
>                 /*
>                  * A 32-bit debugger setting orig_eax means to restore
>                  * the state of the task restarting a 32-bit syscall.
>                  * Make sure we interpret the -ERESTART* codes correctly
>                  * in case the task is not actually still sitting at the
>                  * exit from a 32-bit syscall with TS_COMPAT still set.
>                  */
>                 regs->orig_ax = value;
>                 if (syscall_get_nr(child, regs) >= 0)
>                         task_thread_info(child)->status |= TS_COMPAT;
>                 break;
> 
> which gets used for 32-bit compat ptrace(2).  Perhaps the same logic
> should be added to putreg() if the child is a 32-bit process?

Sounds like the right fix to me.

-- 
Pedro Alves
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.