Neon registers in core files

[Yao Qi]

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.