[SOLVED] problem with jlinkgdbserver with RISCV, got ARM reg-set instead of riscv

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

  • [SOLVED] problem with jlinkgdbserver with RISCV, got ARM reg-set instead of riscv

    I had a debugging model of following:
    gdb <--> jlinkgdbserver <--> jlink <--> RISCV board

    when I issue "monitor regs" from gdb, I got ARM regsters set:

    (gdb) monitor regs
    X0 = 00000000, X1 = 7001CA5A, X2 = 7001F6B0, X3 = 22400150
    X4 = 405D3080, X5 = 64000038, X6 = 00000025, X7 = 64000030
    X8 = 0014112D, X9 = 00000001, X10= 7001D062, X11= 00000000
    X12= 00000000, X13= 00000000, X14= 00000000, X15= 64000000
    X16= 7001D490, X17= 00000015, X18= 00000002, X19= 00000003
    X20= 00000003, X21= 00000002, X22= 00000001, X23= 64000020
    X24= 64000018, X25= 0C006200, X26= 10459C04, X27= 00242120
    X28= 00000009, X29= 00000000, X30= 00000000, X31= 64000040
    PC = 7001CA5A

    and log from JlinkGDBserver
    Received monitor command: regs
    X0 = 00000000, X1 = 7001CA5A, X2 = 7001F6B0, X3 = 22400150
    X4 = 405D3080, X5 = 64000038, X6 = 00000025, X7 = 64000030
    X8 = 0014112D, X9 = 00000001, X10= 7001D062, X11= 00000000
    X12= 00000000, X13= 00000000, X14= 00000000, X15= 64000000
    X16= 7001D490, X17= 00000015, X18= 00000002, X19= 00000003
    X20= 00000003, X21= 00000002, X22= 00000001, X23= 64000020
    X24= 64000018, X25= 0C006200, X26= 10459C04, X27= 00242120
    X28= 00000009, X29= 00000000, X30= 00000000, X31= 64000040
    PC = 7001CA5A

    if I did it from JLink prompt:
    J-Link>regs
    pc = 000000007001DE5C sp = 000000007001FB70 ra = 000000007001E048
    gp = C96B449222400910 tp = 6801201A404DA080 fp = 0000000000000001
    t0 = 0000000000006000 t1 = 0000000000000025 t2 = 00000000000000FF
    t3 = 0000000000000009 t4 = 0000000000000000 t5 = 0000000000000000 t6 = 0000000070001000
    a0 = 000000007001FBA0 a1 = 0000000000000003 a2 = 0000000000000000 a3 = 000000007001D630
    a4 = 0000000000000000 a5 = 000000007001D590 a6 = 000000007001FBC0 a7 = 0000000000000015
    s1 = 0000000000000002 s2 = 0000000000000003 s3 = 1E85121402203004 s4 = 09A92352240C6800
    s5 = 0021202000817A20 s6 = 980C0921920840F2 s7 = 4F50044898000060 s8 = 4A08101182132801
    s9 = 5125CF320C004200 s10 = 2426400010419804 s11 = D005488200242121

    Here are the command line and configurations that I used to bring up these tools:

    /usr/bin/JLinkExe -device RV64 -if JTAG -speed 4000 -jtagconf -1,-1 -autoconnect 1 -Log ~/jlink.log
    /usr/bin/JLinkGDBServerCLExe -select USB -device FE310 -endian little -if JTAG -speed 40

    So, what went wrong ?

  • Hi,

    Nothing went wrong.
    Not sure why you think that X0-X31 are ARM registers.
    The RISC-V spec. shows that these are perfectly valid register identifiers. As for ARM, there may be multiple ways on assembly level to address a register (ARM for example: R13 / SP, R15 / PC, ...)
    riscv.org/wp-content/uploads/2015/01/riscv-calling.pdf
    (See excerpt attached)

    For J-Link Commander we changed the names to the ABI names some time ago.
    For GDBServer things are slightly more difficult because we need to stay in line with the protocol definition.
    sourceware.org/gdb/current/onl….html#RISC_002dV-Features

    At the time we added GDB support, this spec. did not really exist yet.
    It was in beta status.
    However, the spec. now says that either x0-x31 may be used or zero, ra, ...

    We will consider changing the register names for J-Link GDBServer as well as the current head of the GDB git repo uses zero, ra, ... as well.

    Nevertheless, this is not a bug.


    BR
    Alex
    Images

    • RV_Regs.png

      103.94 kB, 607×514, viewed 389 times
    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.

  • ok, got it.
    Thanks !

    Another problem:
    Tried to change PC value from gdb, but PC did not change,

    (gdb) monitor reg pc 0x7001dc04
    Writing register (#32 = 0x7001DC04)


    log from JlinkGDBserver
    Received monitor command: reg pc 0x7001dc04
    Writing register (#32 = 0x7001DC04)

    Verified with JLink command:
    J-Link>regs
    pc = 000000007001C2BE sp = 000000007001FB70 ra = 000000007001DF56
    gp = C96B448222400110 tp = 6801221A405D3080 fp = 0000000000000000
    t0 = 0000000000001830 t1 = 0000000000000000 t2 = 0000000000001828

    This looks the command did not get through from gdbserver to jlink
    Checked JLink logging, I don't see the logging of setting PC, only logging of reading regs:

  • Hi,

    You need to be careful with monitor commands.
    Monitor commands are simply passed by GDB to GDBServer.
    GDB does not know what they do but seems to expect them to not change any registers. (There is no real documentation about this)
    GDB has its own register cache.
    You need to perform a "flushregs" command after the monitor command to make GDB seeing the register change.
    There are also commands to manipulate registers right in GDB. For these commands, GDB is aware of the change and will not need the flushregs command.

    J-Link GDBServer is not open source, so there is no place where you can download the sources.


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

  • The problem is not about gdb, because gdb shows PC got changed:
    (gdb) monitor reg pc 0x7001DDDC
    Writing register (#32 = 0x7001DDDC)
    (gdb) monitor reg pc
    Reading register (#32 = 0x7001DDDC)

    The problem is between JLinkGDBserver and JLink

    The logging of JLinkGDBserver shows
    Received monitor command: reg pc 0x7001DDDC
    Writing register (#32 = 0x7001DDDC)

    verified with JLink command "regs" which shows PC did not get changed.
    The logging of JLink shows it did not receive the "setpc" command from JLinkGDBserver.

    Another question:
    If I buy your J-Link SDK, will I get your JLinkGDBserver source ?

  • Again:monitor commands bypass GDB logic and go directly into GDBServer.

    So:
    monitor reg pc = xxx
    monitor reg pc
    Will of course show the change. Both by pass GDB logic and go directly into GDBServer.

    If you do:
    monitor reg pc = xxx
    info registers

    You will probably not see the change because the 2nd command goes to GDB and the first command bypassed GDB.

    Now you complicated things by starting a 2nd process that accesses J-Link and which GDBServer is not aware of.
    GDBServer as well as GDB has a cache, so a "monitor reg pc = xxx" does not mean that things are written to hardware directly (same as CPU + cache + DMA on a embedded device).
    If you now start J-Link Commander and type "regs" it may show old values.
    Same if you write a register via J-Link Commander and afterwards read it via "monitor reg xxx". J-Link Commander, GDBServer, GDB, ... all have their own caches.
    The caches are usually flushed on "go" (when resuming execution of the target application)

    The source of GDBServer is not part of the SDK.
    If you desperately need the source, we recommend to get in touch with sales directly and see if we can work something out.

    I still don't understand what exactly you are trying to do.
    If you want to debug on RISC-V, then why not starting Eclipse + GDB + GDBServer and start debugging?
    Why disassembling the engine and introducing dozen of processes that all access the target in parallel and run into problems with application caches.


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

  • Thanks!

    I'm trying to debug my app on RISCV hardware, but I can not use J-Link flash download the app to hardware.
    I tried, it did not work for me. That's why I can not use what you recommended:

    Eclipse + GDB + GDBServer and start debugging.



    My debugging sequence is as following:

    1. start execute app on hardware
    2. start JLinkExe
    3. start JLinkGDBServer
    4 . start gdb

    As you can see I did not start 2nd JLink that gdbserver is not aware of.
    I also verified with 'ps -elf' to make sure there is only one JLink process running.

    This debugging model worked well initially if I did only "monitor halt" "monitor go", I can see app stop and go,
    the logging of JLink and gdbserver also show these commands went through, but when it came to manipulate register, it encountered the problems that I described above.

    So, I still insist the problematic part is in between gdbserver and JLink, somehow gdbserver did not pass
    "setpc..." command to JLink, note, read register worked.

    BTW, if I do low level debugging directly from JLink, everything works fine.

  • Hi,

    chihinko wrote:

    As you can see I did not start 2nd JLink that gdbserver is not aware of.
    Alex was not referring to two JLinkExe processes, but to two connections to the same J-Link and the same device:
    You do have two connections to the same J-Link debug probe and the same target device:
    1. JLinkExe <-> J-Link debug probe <-> target
    2. JLinkGDBServer <-> J-Link debug probe<-> target

    The JLinkGDBServer is only aware of its own connection and the commands issued from the GDB.
    Neither JLinkGDBServer nor JLinkExe can "know" what the other process does.
    This is causing a cache problem for each of the J-Link sessions (JLinkExe <-> J-Link and JLinkGDBServer <-> J-Link), as Alex explained in his last message.
    If you write the register with one process (in your case JLinkGDBServer), the cache of the other process (in your case JLinkExe) is not updated.

    SEGGER - Alex wrote:

    I still don't understand what exactly you are trying to do.
    If you want to debug on RISC-V, then why not starting Eclipse + GDB + GDBServer and start debugging?
    Why disassembling the engine and introducing dozen of processes that all access the target in parallel and run into problems with application caches.
    Could you please also answer this question?

    Best regards,
    Fabian
    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.

  • OK, I got it, JLinkGDBServer would start it's own connection to J-Link debug probe<-> target,
    I misunderstood that I have to start JLinkExe for JLinkGDBServer to connect to,

    I thought the debugging model is


    gdb <--> JLinkGDBServer <--> JLinkExec <--> J-Link debug prob <--> target


    Now, if I don't start JLinkExe then everything works well.

    Thanks a lot !

  • Hi,
    Good to hear that you are up and running again.

    We will close this thread now.

    Best regards,
    Fabian
    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.