Debugging NEON registers

Hey guys.

I'm developing code right on the board using Source Navigator + make
files and debugging via GDB and Insight. The main problem is that GDB
can't see the NEON registers.... and I need to see those for what I'm
doing!

Anybody figure this out?

Fred

Phred <phredo@gmail.com> writes:

Hey guys.

I'm developing code right on the board using Source Navigator + make
files and debugging via GDB and Insight. The main problem is that GDB
can't see the NEON registers.... and I need to see those for what I'm
doing!

Anybody figure this out?

The latest codesourcery gdb should have this ability.

Yes. You'll need all the following:
  - CS 2009q1 release or later (to be released soon)
  - kernel 2.6.29 as-is, or 2.6.28 kernel with following patches
    * [ARM] 5388/1: Add hwcap bits for VFPv3 and VFPv3D16
    * [ARM] 5387/1: Add ptrace VFP support on ARM
    * Add HWCAP_NEON to the ARM hwcap.h file
  - gdb needs to be built with expat libs available
  - you need to use gdbserver rather than fully hosted debug

With this, you are able to display all NEON/VFPv3 registers. Here's
an example:

(gdb) target remote 127.0.0.1:1234
Remote debugging using 127.0.0.1:1234
0x400007b0 in ?? ()
(gdb) cont
Continuing.
^C
Program received signal SIGINT, Interrupt.
0x00008b34 in ?? ()
(gdb) info all-registers
r0 0xbef54624 -1091221980
r1 0x0 0
r2 0xbef5161c -1091234276
r3 0xbef56408 -1091214328
r4 0x595d 22877
r5 0x376 886
r6 0xbef56408 -1091214328
r7 0xbef56420 -1091214304
r8 0xbef56410 -1091214320
r9 0xbef523fc -1091230724
r10 0x11400 70656
r11 0xbef553fc -1091218436
r12 0xbef52624 -1091230172
sp 0xbef513b0 0xbef513b0
lr 0xbef55624 -1091217884
pc 0x8b68 0x8b68
cpsr 0x20000010 536870928
d0 {u8 = {0xfb, 0xfe, 0xff, 0xff, 0x0, 0x0, 0x0, 0x0}, u16
= {
    0xfefb, 0xffff, 0x0, 0x0}, u32 = {0xfffffefb, 0x0}, u64 =
0xfffffefb,
  f32 = {0x0, 0x0}, f64 = 0x0}
d1 {u8 = {0xff, 0xfe, 0xff, 0xff, 0x0, 0x0, 0x0, 0x0}, u16
= {
    0xfeff, 0xffff, 0x0, 0x0}, u32 = {0xfffffeff, 0x0}, u64 =
0xfffffeff,
  f32 = {0x0, 0x0}, f64 = 0x0}
<snip>

(gdb) print $d3
$1 = {u8 = {202, 239, 255, 255, 0, 0, 0, 0}, u16 = {61386, 65535, 0,
0},
  u32 = {4294963146, 0}, u64 = 4294963146, f32 = {-nan(0x7fefca), 0},
  f64 = 2.1219937405928421e-314}
(gdb) print $d3.u8
$2 = {202, 239, 255, 255, 0, 0, 0, 0}
(gdb) print/x $d3.u8
$3 = {0xca, 0xef, 0xff, 0xff, 0x0, 0x0, 0x0, 0x0}

hi ,

With
- CS 2009q1 release or later (to be released soon)
- kernel 2.6.29 and gdb server I m not able to see the neon
registers .
M I missing something?

Kindly help.

Regards,
Niral

Hi Friends,

Problem Solved.
The missing part was gdbserver.
I was using very old gdbserver(6.7.1 - gdb released) but we need to
build gdb server from the same release of gdb(CS 2009q1 release).

Thank you all !!!
Many thanks to Ian.

Regards,
Niral

Hey Niral.

We actually did the same thing and it didn't work out for us. Could
you explain the exact steps you did? We didn't find the expat libs
either but we did rebuild GDBSERVER with the CS 2009q1 tool chain.

Fred

Phred <phredo@gmail.com> writes:

Fred,

- I downloaded the cs 2009q1 code from the code sourcery and built the
gdbserver from it.
- On kernel kernel 2.6.29.1 applied following patches:

             1) [ARM] 5387/1: Add ptrace VFP support on ARM.

             2) [ARM] 5388/1: Add hwcap bits for VFPv3 and VFPv3D16.

             3) Add HWCAP_NEON to the ARM hwcap.h file.

             4) Enable neon and vfp support in kernel in config file-
By Enabling macro.
- Use gdb from the CS 2009q1 release.
- I have used arm-2009q1-176-arm-none-linux-gnueabi source code for
gdb and gdbserver.

Regards,
Niral

And where could one find said patches?

Phred wrote:

And where could one find said patches?

where did you search for them?

e.g. <http://www.google.com/search?q=[ARM]+5387%2F1%3A+Add+ptrace+VFP+support+on+ARM>

No I mean what is the standard way of getting and installing a PATCH?
I know they come in .PATCH files....

Phred wrote:

No I mean what is the standard way of getting and installing a PATCH?
I know they come in .PATCH files....

I am inclined to reply to you again: "did you google for it?"

In fact I did..... wanna know where the very first link brought me?
RIGHT BACK HERE! LOL

I also found a link to a GIT repository which is where I initially
looked so I'm assuming I'm getting closer.

Whatever I'll figure it out sooner or later.

Hi Phred

The patches are in the kernel.org tree. In fact, 2.6.29 is working
now on Beagle complete with EHCI, so you could just grab a binary
image off Robert Nelson's site or Angstrom download and save yourself
a lot of bother.
http://www.angstrom-distribution.org/demo/beagleboard/

The list of specific patches was so that people could use 2.6.28 which
was the latest reliable kernel at the time I posted the original
requirements on 26-Apr.

CS2009q1 release is also available prebuilt which should help too

Can you please report back when you get it going?

Ok I had stopped working on this issue for a while but now I'm back on
it. Here is what I've done.

* GIT'd the latest tree and rebuilt the kernel. Uname -a shows this:
Linux BeagleOne 2.6.29-omap1 #1 Mon Jul 13 14:36:12 EDT 2009 ARMv7l
GNU/Linux

* Using CodeSourcery's 2009Q1 tool-chain. Copied the gdbserver from
there to the BeagleBoard.

* on the BB I do gdbserver IP:PORT APP and on my Ubuntu Linux host
machine, I run arm-none-linux-gnueabi-gdb and then do target remote
IP:PORT. From there info all-registers. It spits out info on R0-R9
and F0-F7 but no NEON register info.

I had read about the patches but that was only for the .28 kernel.

The only other thing I can think of is that I have to run both GDB
Server and Client built to recognise NEON registers right on the BB
itself. Is that the case?

Fred