1

I am using gdb (arm-none-eabi) with a Texas Instruments Hercules (Cortex-R4F) processor. I'm using Texas Instrument's XDS agent as a remote GDB server

After running 

target remote ip:port

in GDB, GDB will connect with the XDS GDBserver. I can then print the registers

info all-registers

It shows me the CPU registers, but also f7 and fpa registers which lead me to conclude that the CPU has an floating point coprocessor (FPA). This is however not the case. The processor has vfpv3. So GDB is using the wrong register definitions which leads to problems.

I tried to find the info in the packets sent by XDS GDB server by setting

set debug remote 1

but could not find any info. How does GDB determine the register definitions to use?

Update: I found the set architecture command:

set architecture

>Requires an argument. Valid arguments are arm, armv2, armv2a, armv3, armv3m, armv4, armv4t, armv5, armv5t, armv5te, xscale, ep9312, iwmmxt, iwmmxt2, arm_any, auto.

Cortex-R4f is armv7 with vfpv3. How can I set it?

artless noise
  • 21,212
  • 6
  • 68
  • 105
dwjbosman
  • 906
  • 9
  • 33
  • First and foremost like the compiler, assembler, linker it is compiled for ARM. But beyond that is is likely generic unless you tell it specifically what you have. Older arms dont have CPUID stuff that newer ones do so it cant detect. What was your command line, was there an option to specify architecture? – old_timer Apr 12 '17 at 17:52
  • I wouldnt expect to know lets say it that way. – old_timer Apr 12 '17 at 17:52
  • or saying it yet another way. like the toolchain, the human knows, but the tool maybe not, so the human tells the tool... – old_timer Apr 13 '17 at 02:31
  • Ok, but how do I specify the architecture to use? The moment I connect with the remote target (even before loading any programs) gdb already assumes the wrong register set. – dwjbosman Apr 13 '17 at 08:04
  • Sounds like you need a gdb/toolchain that understands armv7. For the common registers r0 to r15, cpsr, etc is it getting it wrong? Or is it just for coprocessors? – old_timer Apr 13 '17 at 14:12
  • Gdb is talking to something else that is talking to the board/chip, that something else no doubt knows what chip you have or close enough to get through/in. But the gdb interface is more generic and they may be translating 90% of what you need correctly and just not knowing you dont have an fpu or something like that. – old_timer Apr 13 '17 at 14:14
  • Stop using 'Texas Instrument's XDS agent as a remote GDB server' and use a 'gdb server' that is compiled with the remote host GDB compiled for ARM. What does `show arm fpu` say? If there is an issue with XDS agent how can GDB fix it? You don't have a gdbserver, so why that tag? The *gdbsever* and the host *gdb* need to match or you usually have issues, especially as ARM may have several variants from configuration. Your host GDB may not even understand ARMv7 instructions. – artless noise Apr 13 '17 at 15:10

1 Answers1

2

TI's XDS agent is acting as a GDBServer.

But it does not respond to packets such as qXfer:features:read... to get information on the target

In the end I manually applied:

set tdesc filename /gdb/binutils-gdb/gdb/features/arm/arm-with-vfpv3.xml

this sets the correct features for the Corter-R4f and allows me to set breakpoints, call functions, etc.

Alas, we're finding other problems now. It seems TI's XDS GDBserver agent is not very stable.

dwjbosman
  • 906
  • 9
  • 33