[RFC] ptrace: add generic SET_SYSCALL request

[takahiro.akashi@linaro.org (AKASHI Takahiro)]

Ulrich, Arnd, thank you for your discussions:

On 11/14/2014 07:25 AM, Arnd Bergmann wrote:
> On Thursday 13 November 2014 15:49:20 Ulrich Weigand wrote:
>> Arnd Bergmann <arnd@arndb.de> wrote on 13.11.2014 11:21:28:
>>
>>> I have to admit that I don't really understand gdb internals, but from
>>> a first look I get the impression that it will just do the right thing
>>> if you reuse NT_S390_SYSTEM_CALL on ARM64 with the same semantics.
>>
>> There's an interface between BFD and GDB proper involved here.  BFD will
>> detect the presence of register set notes in the core dump, and will
>> translate them into virtual sections; GDB will then simply look up such
>> sections under well-known names.
>>
>> In particular, the NT_S390_SYSTEM_CALL note will be translated by BFD
>> into a virtual section named ".reg-s390-system-call"; GDB platform-
>> specific code will look for sections of this particular name.
>>
>> So if you were to create notes using the same note type, by default it
>> would do nothing on ARM64.  You might add code to the ARM64 back-end
>> to also look for a section ".reg-s390-system-call", but that would be
>> somewhat confusing.  Using a new, platform-specific note type for ARM64
>> would appear to fit better with existing precedent.

I implemented a regset of NT_SYSTEM_CALL(=NT_S390_SYSTEM_CALL) experimentally,
and checked a generated core file:

 >$ aarch64-linux-gnu-readelf -Wn <...>/tmp/nulltest/core
 >
 >Displaying notes found at file offset 0x000003c0 with length 0x00000a68:
 >  Owner                 Data size    Description
 >  CORE                 0x00000188    NT_PRSTATUS (prstatus structure)
 >  CORE                 0x00000088    NT_PRPSINFO (prpsinfo structure)
 >  CORE                 0x00000080    NT_SIGINFO (siginfo_t data)
 >  CORE                 0x00000130    NT_AUXV (auxiliary vector)
 >  CORE                 0x000001b4    NT_FILE (mapped files)
 >    Page size: 4096
 >                 Start                 End         Page Offset
 >[snip]...
 >  CORE                 0x00000210    NT_FPREGSET (floating point registers)
 >  LINUX                0x00000008    NT_ARM_TLS (AArch TLS registers)
 >  LINUX                0x00000108    NT_ARM_HW_BREAK (AArch hardware breakpoint registers)
 >  LINUX                0x00000108    NT_ARM_HW_WATCH (AArch hardware watchpoint registers)
 >  LINUX                0x00000004    NT_S390_SYSTEM_CALL (s390 system call restart data)

Looks funny:)

> Ok, thanks a lot for your insight and for confirming what Takahiro AKASHI
> said. Let's use a new NT_ARM64_SYSTEM_CALL type with a different
> number then.

We will use NT_ARM_SYSTEM_CALL(=0x404) as other NT_ARM_*, except NT_ARM_VFP,
are also shared by arch/arm and arch/arm64.

Anyhow, gdb (and/or binutils?) should be updated as well once my coming patch is merged.
My next question is who should know this?

Thanks,
-Takahiro AKASHI

> 	Arnd
>