代码之家  ›  专栏  ›  技术社区  ›  MulattoKid

GDB和LinkServer/MCULink的断点触发速度慢

nxp-microcontroller gdbserver gdb
  •  0
  • MulattoKid  · 技术社区  · 10 月前

    我正在进行一个涉及恩智浦I.MX RT1060的项目,我正在使用恩智浦的MCULink进行调试。我使用恩智浦的LinkServer运行GDB服务器,并使用VSCode中的Cortex Debug扩展来运行GDB。最后,该项目正在使用ThreadX RTOS运行。以下是版本信息: 

    Ubuntu 22.04 (x86_64)
VSCode v1.91.1
cortex-debug v1.12.1
GDB multiarch v12.1
LinkServer v1.5.30
MCU-LINK (r0FF) CMSIS-DAP V3.140

    现在,我遇到的问题是,当断点被触发时,系统中有15个或更多线程处于活动状态,需要很长时间(>30秒)才能将我带到断点并允许我与调试器交互。如果有14个或更少,它会“瞬间”发生。我尝试过的事情如下:

    • 我查看了GDB的输出日志,发现当GDB运行缓慢时,会出现数据包错误消息( Ignoring packet error, continuing... )但是 不 当它很快的时候。这些出现在 thread-info N 在系统中的各个线程上调用
    • 我已经设定好了 set remotetimeout 1 (默认值为2),当速度较慢时,这会加快速度,但仍然很慢
    • 我已经设定好了 set debug remote 1 ,这给了我以下输出: 
    0000018993+00000: -> ~"Thread 7 hit Breakpoint 2, app () at /workspaces/connected2/app/src/app.cpp:652\n"
0000018993+00000: Thread 7 hit Breakpoint 2, app () at /workspaces/connected2/app/src/app.cpp:652
0000018993+00000: -> ~"652\t            auto message = application_queue->receive(Wait::DontWait());\n"
0000018993+00000: 652               auto message = application_queue->receive(Wait::DontWait());
0000018993+00000: -> *stopped,reason="breakpoint-hit",disp="keep",bkptno="2",frame={addr="0x6011da94",func="app",args=[],file="/workspaces/connected2/app/src/app.cpp",fullname="/workspaces/connected2/app/src/app.cpp",line="652",arch="armv7e-m"},thread-id="7",stopped-threads="all"
0000018993+00000: mi2.status = stopped
0000018994+00001: 31-thread-list-ids
0000018994+00000: -> &"[remote] Sending packet: $qfThreadInfo#bb\n"
0000018994+00000: [remote] Sending packet: $qfThreadInfo#bb
0000019002+00008: -> &"[remote] Received Ack\n"
0000019002+00000: [remote] Received Ack
0000019002+00000: -> &"[remote] Packet received: m20015AB8,20002230,20002410,20002500,20002320,200028C0,200027D0,200026E0,200025F0,2003A810,20039158,2003B5F0,200029B0,20002AA0,20002B90,20002C80,20002D70,20002E60,20002F50\n"
0000019002+00000: [remote] Packet received: m20015AB8,20002230,20002410,20002500,20002320,200028C0,200027D0,200026E0,200025F0,2003A810,20039158,2003B5F0,200029B0,20002AA0,20002B90,20002C80,20002D70,20002E60,20002F50
0000019002+00000: -> &"[remote] Sending packet: $qsThreadInfo#c8\n"
0000019002+00000: [remote] Sending packet: $qsThreadInfo#c8
0000019002+00000: -> &"[remote] Received Ack\n"
0000019002+00000: [remote] Received Ack
0000019002+00000: -> &"[remote] Packet received: lOK\n"
0000019002+00000: [remote] Packet received: lOK
0000019002+00000: -> 31^done,thread-ids={thread-id="2",thread-id="3",thread-id="4",thread-id="5",thread-id="6",thread-id="7",thread-id="8",thread-id="9",thread-id="10",thread-id="11",thread-id="12",thread-id="13",thread-id="14",thread-id="15",thread-id="16",thread-id="17",thread-id="18",thread-id="19",thread-id="20"},current-thread-id="7",number-of-threads="19"
0000019002+00000: 32-thread-info 2
0000019002+00000: -> &"[remote] Sending packet: $qfThreadInfo#bb\n"
0000019002+00000: [remote] Sending packet: $qfThreadInfo#bb
0000019008+00006: -> &"[remote] Received Ack\n"
0000019008+00000: [remote] Received Ack
0000019008+00000: -> &"[remote] Packet received: m20015AB8,20002230,20002410,20002500,20002320,200028C0,200027D0,200026E0,200025F0,2003A810,20039158,2003B5F0,200029B0,20002AA0,20002B90,20002C80,20002D70,20002E60,20002F50\n"
0000019008+00000: [remote] Packet received: m20015AB8,20002230,20002410,20002500,20002320,200028C0,200027D0,200026E0,200025F0,2003A810,20039158,2003B5F0,200029B0,20002AA0,20002B90,20002C80,20002D70,20002E60,20002F50
0000019008+00000: -> &"[remote] Sending packet: $qsThreadInfo#c8\n"
0000019008+00000: [remote] Sending packet: $qsThreadInfo#c8
0000019008+00000: -> &"[remote] Received Ack\n"
0000019008+00000: [remote] Received Ack
0000019008+00000: -> &"[remote] Packet received: lOK\n"
0000019008+00000: [remote] Packet received: lOK
0000019008+00000: -> &"[remote] Sending packet: $qThreadExtraInfo,20002d70#44\n"
0000019008+00000: [remote] Sending packet: $qThreadExtraInfo,20002d70#44
0000019020+00012: -> &"[remote] Received Ack\n"
0000019020+00000: [remote] Received Ack
0000019020+00000: -> &"[remote] Packet received: 226d6f64756c65732f6d6963726f6f63707022203a2054585f534c454550\n"
0000019020+00000: [remote] Packet received: 226d6f64756c65732f6d6963726f6f63707022203a2054585f534c454550
0000019020+00000: -> &"[remote] Sending packet: $Hg20002d70#6e\n"
0000019020+00000: [remote] Sending packet: $Hg20002d70#6e
0000019020+00000: -> &"[remote] Received Ack\n"
0000019020+00000: [remote] Received Ack
0000019020+00000: -> &"[remote] Packet received: OK\n"
0000019020+00000: [remote] Packet received: OK
0000019020+00000: -> &"[remote] Sending packet: $g#67\n"
0000019020+00000: [remote] Sending packet: $g#67
0000019026+00006: -> &"[remote] Received Ack\n"
0000019026+00000: [remote] Received Ack
0000019026+00000: -> &"[remote] read_frame: Bad checksum, sentsum=0x25, csum=0xe2, buf=000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000ce924200000000000000000\\000002B90,20002C80,20002D70,20002E60,20002F50\n"
0000019026+00000: [remote] read_frame: Bad checksum, sentsum=0x25, csum=0xe2, buf=000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000ce924200000000000000000\000002B90,20002C80,20002D70,20002E60,20002F50
0000020027+01001: -> &"[remote] getpkt_or_notif_sane_1: Timed out.\n"
0000020027+00000: [remote] getpkt_or_notif_sane_1: Timed out.
0000021028+01001: -> &"[remote] getpkt_or_notif_sane_1: Timed out.\n"
0000021028+00000: [remote] getpkt_or_notif_sane_1: Timed out.
0000021028+00000: -> ~"Ignoring packet error, continuing...\n"
0000021028+00000: Ignoring packet error, continuing...
0000021029+00001: -> 32^done,threads=[{id="2",target-id="Thread 536882544",details="\"modules/microocpp\" : TX_SLEEP",frame={level="0",addr="0x00000000",func="??",args=[],arch="armv7e-m"},state="stopped"}]

    正如日志所示,一切似乎都很好,直到 read_frame 得到一个错误的校验和,以及 getpkt_or_notif_sane_1 超时。然而,即使发生了一些错误,实际的线程信息也能正常检索,调试似乎工作正常,但每一步进入/结束并继续都同样缓慢。

    我试过了 reaching out to NXP ,但还没有收到回复,所以我想知道是否有人知道导致这种情况的原因,以及是否有办法解决它?

    0 回复  |  直到 10 月前
        1
  •  1
  •   Andrew    10 月前

    您看到的缓慢行为100%是由校验和错误引起的,我几乎可以肯定,这是由于远程目标发送了错误的校验和,或者远程目标和GDB之间的“线路”损坏造成的。

    我这么说很有信心,因为GDB中的校验和计算代码多年来没有改变,而且我 从未 发现了一个不是由远程目标引起的校验和问题。

    当GDB收到校验和错误时,它会发送一个NAK数据包( - )返回远程并等待重新发送,此行为会被记录下来 here .GDB将等待远程超时,发送另一个NAK数据包,然后再次等待。GDB将尝试3次获取数据包,然后放弃。

    这与您的调试跟踪一致,第一次尝试确实会产生一个数据包,但校验和是错误的。接下来的两次尝试都超时了,然后GDB继续前进。

    根据您提供的证据,我认为在这种情况下,GDB的行为符合预期,远程目标出现了以下两个问题:

    1. 发送错误的校验和以响应 g 包,以及
    2. 不处理来自GDB的NAK回复——尽管我怀疑大多数目标可能认为连接是可靠的,所以不要正确处理NAK。不过,如果目标发现了来自GDB的NAK,意识到事情出了问题并发出错误信号,那就太好了。

    我知道这个答案无助于解决你的问题,但我想我会尽我所能补充一下。

    推荐文章
    关于  
    代码之家 - 一站式码农服务社区
    沪ICP备11025650号