Monday, May 21st 2018, 7:04pm UTC+2

You are not logged in.

  • Login
  • Register

Dear visitor, welcome to SEGGER Forum. If this is your first visit here, please read the Help. It explains how this page works. You must be registered before you can use all the page's features. Please use the registration form, to register here or read more information about the registration process. If you are already registered, please login here.



Date of registration: Jun 24th 2012

Posts: 32


Thursday, December 6th 2012, 12:28pm

GDB server4.56d/4.58 : no registers any more (g-packet template change)


It seems that the version 4.56d and up has changed the g-packet template for the Cortex-M devices. From 4.28b upto 4.50j I had no problems.

The response for retrieving the registers:

^error,msg="Could not fetch register \"f7\"; remote failure reply 'E01'"

The register names


GDB version 4.7.1

Why is this changed and can this be altered by a command-line switch?
Does support JLink qXfer of the target XML?


This post has been edited 4 times, last edit by "EmBlocks" (Dec 6th 2012, 3:17pm)



Date of registration: Jun 24th 2012

Posts: 32


Thursday, December 6th 2012, 5:06pm

I saw that I didn't use the libexpat so the qXfer of the XML did go wrong.

I also saw that the g-packet has now changed from 168, 68 in older versions in 92 bytes long.
How does the g-packet template look like in this newer versions?

This post has been edited 1 times, last edit by "EmBlocks" (Dec 11th 2012, 12:42pm)



Date of registration: Jun 24th 2012

Posts: 32


Thursday, December 6th 2012, 8:10pm

For all of you who need a guessing structure in the guess list, the new Segger 'g'-packet template for the Cortex-M's is:

<!DOCTYPE feature SYSTEM "gdb-target.dtd">
<feature name="seggers.own.cortex_m.profile">
<reg name="r0" bitsize="32"/>
<reg name="r1" bitsize="32"/>
<reg name="r2" bitsize="32"/>
<reg name="r3" bitsize="32"/>
<reg name="r4" bitsize="32"/>
<reg name="r5" bitsize="32"/>
<reg name="r6" bitsize="32"/>
<reg name="r7" bitsize="32"/>
<reg name="r8" bitsize="32"/>
<reg name="r9" bitsize="32"/>
<reg name="r10" bitsize="32"/>
<reg name="r11" bitsize="32"/>
<reg name="r12" bitsize="32"/>
<reg name="sp" bitsize="32" type="data_ptr"/>
<reg name="lr" bitsize="32"/>
<reg name="pc" bitsize="32" type="code_ptr"/>
<reg name="xpsr" bitsize="32" regnum="25"/>
<reg name="MSP" bitsize="32" regnum="91"/>
<reg name="PSP" bitsize="32" regnum="92"/>
<reg name="PRIMASK" bitsize="32" regnum="93"/>
<reg name="BASEPRI" bitsize="32" regnum="94"/>
<reg name="FAULTMASK" bitsize="32" regnum="95"/>
<reg name="CONTROL" bitsize="32" regnum="96"/>

Segger, wouldn't it be nice to be backwards compatible? :evil:
If you introduce new features which are affecting us all who work with GDB, to make this options optional with commandline switches?
Why not, if older GDB's who don't support qXref for target XML's just fall back to older (known) formats?

For all of you who don't us XML (libexpat) and are using guessing packets I have attached a "segger" profile for a guessing structure.

EmBlocks has attached the following file:

This post has been edited 1 times, last edit by "EmBlocks" (Dec 6th 2012, 8:16pm)

SEGGER - Johannes

Super Moderator

Date of registration: Aug 31st 2012

Posts: 379


Wednesday, February 20th 2013, 2:20pm

GDB version 7.2 (and earlier) tells GDB Server to use the alternate register set and requested a target description from GDB Server,
but did not handle it because of a bug with recognizing the architecture of the target and the target file.
In order to this, GDB requests registers which were not present in the target description used and provided by GDB Server.

To check for this problem connect GDB to GDB Server with the command

Source code

"(gdb) target remote localhost:2331"

This will rise following warning:


"warning: Architecture rejected target-supplied description"
We always recommend to use the latest version of GDB (7.4 or higher).



Date of registration: Jun 24th 2012

Posts: 32


Saturday, February 23rd 2013, 12:18am

Johannes, thanks!

The "problem" was already solved.
I had a normally build of GDB without expat, hence the XML transfer was not done.

Would be nice that, if a gdb doesn't support expat (and there is no XML xfr before g-packets retrieving) that GDB server would act in the normal way (as before).


Super Moderator

Date of registration: Dec 18th 2007

Posts: 1,516


Monday, February 25th 2013, 8:49am


When GDB asks for GDBServer features via "qSupported", GDBServer will have "qXfer:features:read+" in his response if GDBServer has an alternative register set available for the connected CPU.
If GDBServer receives a "xFer:features:read:target.xml" packet from GDB it will use the alternate register set. Otherwise the "old" register set (also used by the versions before we started to support an alternate register set) will be used.
So as long as GDB does not request the target.xml GDBServer will not use it.

Best regards



Date of registration: Jun 24th 2012

Posts: 32


Tuesday, February 26th 2013, 7:17am

That is nice!, version 4.60 didn't do that but just returned the g-packets as if there had an xFer occurred which throw a "g-packet too long".
JLink is working much nicer with expat but expat is not mandatory for GDB.