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/BSPInvestiga...
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.
On Fri, Dec 3, 2010 at 9:06 AM, Yao Qi yao.qi@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/BSPInvestiga... 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-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
On Fri, 3 Dec 2010, Dave Martin wrote:
On Fri, Dec 3, 2010 at 9:06 AM, Yao Qi yao.qi@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/BSPInvestiga... 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
On 12/03/2010 10:57 PM, Dave Martin wrote:
[Apologized for delayed reply]
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.
Exactly. That is why we need your guys' support from kernel side. :)
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:
w.r.t creating a new section in dump, here are some cents from GDB, or even other related tools, point of view,
- GDB has an infrastructure to read register values from sections other than ".reg" and ".reg2". Different targets have to define its own hooks to achieve that. - arm-linux gdb doesn't use this infrastructure, register values are still read from section ".reg" and ".reg2". However, it is not hard to change to use that infrastructure. - No sure how much impact to other related tools. Take readelf for an example. readelf should be change a little bit. Current readelf displays some info like this, Notes at offset 0x00000234 with length 0x00000264: Owner Data size Description CORE 0x0000007c NT_PRPSINFO (prpsinfo structure) [...] After we add extra section in dump, output is like, Notes at offset 0x00000234 with length 0x00000264: Owner Data size Description CORE 0x0000007c NT_PRPSINFO (prpsinfo structure) [...] Notes at offset 0x00000XX with length 0x00000XXX: Owner Data size Description CORE 0x000000XX NT_NEONREGSET (NEON registers) - how easy it will be to make these changes accepted upstreams, both kernel side and toolchain side.
So far, as far as I know about kernel and GDB sides, I prefer "single section" approach a little bit, but "extra section" approach is also acceptable to me. Finally, we need an agreement on this, so any comments/suggestions on this are welcome.
.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.
Due to my very limited knowledge on ARM arch, I have no comment on this.
-
Dave Martin -
Nicolas Pitre -
Yao Qi