RFC: ARM: Support for VFP/NEON registers in coredumps
dave.martin at linaro.org
Fri Mar 25 13:30:21 UTC 2011
On Fri, Mar 25, 2011 at 1:11 PM, Ulrich Weigand
<Ulrich.Weigand at de.ibm.com> wrote:
> Dave Martin <dave.martin at linaro.org> wrote:
>> > So to summarize: the kernel will write additional note sections as if
>> > generated via user_regset_view, containing the PTRACE_GETVFPREGS data.
>> > Note name: "LINUX"
>> Why "LINUX" and not "CORE"? I don't understand the distinction... are
>> the "CORE" notes common to all platforms / all ELF implementations?
> Because that's what user_regset_view would do; all notes except the
> standard ones (NT_PRPSINFO, NT_PRSTATUS, NT_PRFPREG, NT_AUXV) have a
> note name of "LINUX". I'm not completely sure about the rationale,
> but presumably it is indeed because the standard notes are more or less
> common across multiple platforms.
OK -- I'm happy to go along with this. It's easy to change if someone
doesn't like it, though I expect it will be accepted as-is.
>> > Note type: t.b.d. [*]
>> > [*] Looking at elf.h a logical name/value might be:
>> > #define NT_ARM_VFP 0x400 /* ARM VFP/NEON
> registers */
>> > GDB support along those lines ought to be straightforward.
>> It's been suggested that the new note should include a version/flags
>> field alongside the ptrace-like register dump, so that if the format
>> turns out to be inadequate / broken, it can be extended in a
>> compatible way.
>> However, nothing else in the coredump or the ptrace interface seems to
>> have such versioning implementation. Ptrace gets extended by adding
>> more and more ptrace call types instead. Adding version fields, while
>> sensible, seems inconsistent with the current implementation.
>> What's your view on adding a flags field to the VFP state dump?
> Again, if we want to use (or mimic) the user_regset_view mechanism,
> there is no choice in any of this; the content of the note will be
> exactly identical to the content of the ptrace buffer. Since this
> is the way everybody else is using, I think we'd have to have really
> good arguments for deviating from it; I'm not sure I see those.
> The usual way to deal with changes to the register set is to define
> *new* regset structures, which then translates to new ptrace commands
> and new core files notes, which are used instead of or in addition to
> the old ones ...
I was indeed thinking that it might be a good idea to take this
opportunity to migrate to using regsets; though for simplicity, I'll
probably avoid this for the first iteration.
Will this have any impact on the ptrace interface?
More information about the linaro-dev