IMXRT1050-EVKB Debugging Speed

[szenger]

Hello all,
I hope you are doing well!

 

We are using an MIMXRT1051 for some of our products currently. But for simplicity we can use the IMXRT1050-EVKB development board for this topic. Debugging works via SWD via J-Link with a seemingly outdated QSPI driver and in C++. I was following this tutorial: https://visualgdb.com/tutorials/arm/imxrt/

All of this somewhat works, but the debugging is very slow (at least compared to our STM development) and even sometimes just dies. It’s 25 seconds to several minutes from starting debug until hitting the first breakpoint in main.

This is why I wanted to ask here if someone has better ways of debugging these controllers with VisualGDB?

 

 

I hope you can make my colleague’s and my life easier 🙂
Thanks! Best,
Stefan

 

• This topic was modified 2 years, 10 months ago by szenger. Reason: html hiccup

[support]

Hi,

No problem. You can use the timing view in the GDB Session window to quickly find out which commands are taking the most time.

[szenger]

Thank you so much for your reply!

 

I can tell already which commands are responsible for the most delay (see attachments):

1. -break-insert -f …
2. -stack-list-frames --thread 1

Mind the one that takes 29 seconds to complete. If I step into this further, the debugger eventually will just crash and disconnect without an error. Each step into or step over can take several seconds. Even worse, hovering over variables might do the same and/or crash the session.

 

 

Best,
Stefan

Attachments:

You must be logged in to view attached files.

[support]

Hi,

If hovering over the variables causes the gdb session to crash, it is likely caused by partial incompatibility between the debug information used in your settings, and the specific version of gdb. You can try changing both of them as shown below:

• The debug information format (DWARF-2/DWARF-4/etc) can be adjusted via the VS project properties (MSBuild) or target properties (CMake), under C/C++ -> General.
• You can try using other versions of gdb by downloading older ARM toolchains.

The -stack-list-frames command usually takes too long if gdb enters and infinite loop while trying to unwind the stack. You can constrain it by setting a hard limit on the number of unwound frames by adding the set backtrace limit command to additional GDB commands.

The -break-insert command delays could be due to large debugging symbols, or if the breakpoint got resolved to multiple physical addresses (e.g. a function inlined from 10 different places). You can recheck the physical addresses in the output from -break-insert, and also try running “set debug remote 1” before setting the breakpoints, so that gdb will display its communication to the gdb stub. If -break-insert does not result in multiple small packets sent to the stub, the delay comes from gdb trying to parse the debug symbols. This delay can be reduced by stripping the debug information from the source files unlikely to be debugged (see this tutorial) or by using gdb index files.

If you can confirm that manually configuring the index files does result in a consistent speedup, please feel free to share more details, and we will consider adding a setting for managing them automatically.

[szenger]

Hello again. Thanks for your reply!

 

As changing the SWD clock has no effect on the timing, except the flashing process, this also would suggest that the issue is local. I’ve been looking into GDB to create index files. Sadly could not get arm-none-eabi-gdb-add-index to work properly, so I’ve been trying the manual approach via https://sourceware.org/gdb/onlinedocs/gdb/Index-Files.html:

1. c:\sysgcc\arm-eabi_10.3.1_10.2.90_r1\bin\arm-none-eabi-gdb VisualGDB/Debug/NXPiMX
2. save gdb-index .gdb-add-index creates something like NXPiMX.gdb-index-1V35ZY in .gdb-add-index. However, it states Error while writing index for C:\src\gsh\src\fw\VisualGDB\Debug\NXPiMX': rename: Permission denied.
3. C:\src\gsh\src\fw>c:\sysgcc\arm-eabi_10.3.1_10.2.90_r1\bin\arm-none-eabi-objcopy --add-section .gdb_index=indexes\NXPiMX.gdb-index-1V35ZY --set-section-flags .gdb_index=readonly VisualGDB/Debug/NXPiMX VisualGDB/Debug/NXPiMX, which changes the VisualGDB/Debug/NXPiMX file from around 19MB to 20MB.
4. So far, so good in GDB I set index-cache on – however, notice no difference at all. At the end of the session I receive
   show index-cache stats
&"show index-cache stats\n"
Cache hits (this session): 0
Cache misses (this session): 0
   ..which puzzles me. What am I missing to turn on the indexing properly?

 

Aside from that,

• I have tried the same scenario with -ggdb, -g3, -gdwarf-2 -gdwarf-4 but could not see any difference. The crashes mentioned above usually follow timeouts, trying to read the values. In general, if any command goes up to something like 60 seconds the whole debugging session just crashes without any error.
  *EDIT* In raw GDB I receive
  (gdb) break C:\src\gsh\src\fw\Configuration\ConfigurationManager.h:18
../../gdb/gdb/utils.c:671: internal-error: virtual memory exhausted: can't allocate 4064 bytes.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) y
• We use different toolchains already. There is no difference.
• The set backtrace limit command definitely is helpful here, thanks a lot!
• I’ll still have to look into any timing differences when stripping debug information from most of the object files. Though, this probably might not be a good option for most cases. Going to update this next week.

 

 

Thank you!
Best,
Stefan

[support]

Hi,

Your indexing setup appears correct. If you are getting confusing output from gdb, you can try asking at the gdb mailing lists, or checking the gdb source code to understand why the cache doesn’t report any hits.

Another option would be to run the “set debug remote 1” command in gdb. It will force gdb to output all packets it sends to the gdb stub, so you can see if the delay involves any requests to the target.

That said, if you are getting the “virtual memory exhausted” error, it’s likely a gdb bug triggered by something specific about the iMXRT symbols. You can try to narrow it down by stripping the debug information from some object files before the linking, or by building your own gdb executable and stepping through it.

[Author]

Posts