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

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

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

    Hi,

    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

    ["r0","r1","r2","r3","r4","r5","r6","r7","r8","r9","r10","r11","r12","sp","lr","pc","f0","f1","f2","f3","f4","f5","f6","f7","fps","cpsr","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","",""]

    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?

    Regards.

    The post was edited 4 times, last by EmBlocks ().

  • 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?

    The post was edited 1 time, last by EmBlocks ().

  • 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"/>
    </feature>

    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.

    Cheers!
    Files

    The post was edited 1 time, last by EmBlocks ().

  • 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

    1. "(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).
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/
    Or you can contact us via e-mail.

  • 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).

  • Hi,

    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
    Alex
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/
    Or you can contact us via e-mail.

  • 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.

    Regards
    Gerard