lkml.org 
[lkml]   [2014]   [Nov]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC] ptrace: add generic SET_SYSCALL request
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
>


\
 
 \ /
  Last update: 2014-11-14 03:41    [W:0.059 / U:0.076 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site