On Fri, 3 Dec 2010, Dave Martin wrote:
> On Fri, Dec 3, 2010 at 9:06 AM, Yao Qi <[email protected]> wrote:
> > Hi, Kernel WG,
> > Can recent kernel handle NEON registers in corefiles?
> >
> > Seems we've had plan for this in "Ensure full NEON debug support" in
> > https://wiki.linaro.org/WorkingGroups/KernelConsolidation/Specs/BSPInvestigations
> > Any progress on this piece of work? We want to handle NEON registers in
> > corefiles from GDB, which required kernel dump them in corefile first.
>
> Hmmm, actually that bullet may have ended up in the wrong place ...
> since it's not a BSP-specific feature.
>
> Anyway, looking at the kernel code, it looks like the VFP/NEON state
> is not dumped into the core file. If it makes you feel better, the
> state of the obsolete FPE extension registers is dumped, if used :/
>
> My guess is that it shouldn't be hard to dump the VFP/NEON state, but
> GDB and the kernel need to agree on the format.
>
> Rather that trying to hack the existing register dump format in a
> compatible way, I suggest it's simplest if the kernel creates an extra
> section in the dump containing something like:
>
> .long format_version /* reserved for future expansion - must be 0
> */
> .long FPSID
> .long FPSCR
> .long MVFR0 /* or 0 if not present in the hardware */
> .long MVFR1 /* or 0 if not present in the hardware */
> .long d0
> .long d1
> /* ... d2-d14 ... */
> .long d15
> If 32 D-registers in the hardware [
> .long d16
> .long d17
> /* ... d18-d30 ... */
> .long d31
> ]
>
> I believe we don't need any extra flags to indicate whether the MVFRx
> fields are valid, since 0 in these registers indicates the
> VFPv2/legacy behaviour anyway. Note that some VFPv2 implementations
> (such as ARM1176) do provide these registers, and where the hardware
> has them, the kernel can fill them in when doing the coredump.
[...]
One thing that would be nice to consider, is to reuse the magic number
used at the front of signal frame data blocks to identify specific
coprocessor states when those extra and optional states are saved during
a signal delivery. Reusing the same layout which was meant to be
extendable should make the core dump more flexible. See
arch/arm/include/asm/ucontext.h for details. I don't see Neon support
in there yet though...
Nicolas
_______________________________________________
linaro-dev mailing list
[email protected]
http://lists.linaro.org/mailman/listinfo/linaro-dev
