Re: [RFC] ptrace: add generic SET_SYSCALL request
From: AKASHI Takahiro
Date: Thu Nov 13 2014 - 20:40:31 EST
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@xxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/