Dave Martin writes: > Hi all, > > Considering how to add the VFP/NEON register state to Coredumps, > there's no single obvious solution, so I'd like to put this out > for people's comments. > > Currently, the coredump consists of several notes, the interesting > ones currently being: > > * NT_PRSTATUS - general process status, including the integer registers > * NT_FPREGSET - the FPA registers (only present if FPA is in use) > > These notes are duplicated per thread when a multithreaded process > dumps core. > > There are few options I see: > > a) Dump the VFP/NEON state in NT_FPREGSET. > This could be appended to, or in place of the legacy FPA regs, > with flags in a header or (struct elf_prstatus).pr_fpvalid > to describe what was dumped. Old gdb etc. may read the > resulting information as random FPA register contents; > this could perhaps be avoided by always dumping a dummy > FPA regs structure at the start of this note, though this > seems wasteful. > > Possibly, gdb may explode if the NT_FPREGSET note is larger > then expected. I've not investigated this. > > b) Dump the VFP/NEON regs in a note of type NT_PRXFPREG. > This avoids defining a new note type; however, this note type > is really for x86 -- so overloading it in this way may just > be nonsensical / confusing. > > c) Create a new note type specially for this, and dump the > VFP/NEON regs in there. This is closest to the model followed > by ptrace, where PTRACE_GETREGS, PTRACE_GETFPREGS and > PTRAGE_GETVFPREGS are all distinct. > > > Going for (c) seems sanest to me, and also means that old gdb > will just ignore the new data; this is probably what we want. > > Comments are welcome.
Strongly prefer (c) or (b). (a) should be avoided if at all possible: appending to or changing established types is just asking for trouble, unless those types were designed from the start to be self-describing and extensible. _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
