On Fri, Dec 3, 2010 at 9:06 AM, Yao Qi <yao...@linaro.org> 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.

We _should_ be prepared to ignore these fields (or interpret them
differently) if a vendor-specific VFP subarchitecture is specified (by
(FPSID & 0x4000) == 0x4000)

The number of D-registers can be deduced from the FPSID and MVFRx
registers, so we don't need to record it explicitly.

When MVFRx are not present, there are 16 D-registers.
When MVFRx are present, and (MVFR0 & 0xF) >= 2, there are 32 (or more)
D-registers

This is just a sketch -- the ARM ARM is the authoritative reference on
the meanings of these bitfields.


Any views on this?

Cheers
---Dave


>
> _______________________________________________
> linaro-dev mailing list
> linaro-...@lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/linaro-dev
>

_______________________________________________
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

Reply via email to