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. _______________________________________________ linaro-dev mailing list [email protected] http://lists.linaro.org/mailman/listinfo/linaro-dev
