xiaoqizhan opened a new pull request, #18731: URL: https://github.com/apache/nuttx/pull/18731
When GDB opens a coredump file, it first selects a "current thread", and the bt command by default only performs backtracing on this current thread. When there is no dedicated "crash thread marker" for this current thread in NuttX's coredump.elf, it usually degenerates to "the first thread parsed in the core file". *Note: Please adhere to [Contributing Guidelines](https://github.com/apache/nuttx/blob/master/CONTRIBUTING.md).* ## Summary This change is necessary to fix the incorrect default current thread selection behavior of GDB when loading NuttX coredump files. When GDB opens a coredump, it automatically selects a "current thread", and the bt backtrace command only acts on this thread by default. In the original implementation, NuttX's coredump.elf does not contain a dedicated "crash thread marker", and without NT_SIGINFO information to identify the crash address, crash signal, and signal-sending thread, GDB falls back to selecting the first parsed thread in the core file as the current thread, which is almost never the actual crashed thread. This change modifies the coredump thread saving logic to write the crashed thread (the thread containing NT_SIGINFO information) as the first thread in the coredump file. This approach reliably overrides GDB's default thread selection policy, regardless of GDB version variations (some GDB versions rely on the first NT_PRSTATUS entry when no explicit stop signal/thread is present). By placing the crashed thread first, GDB will automatically select it as the default current thread, allowing developers to directly use the bt command to obtain the correct crash backtrace without manual thread switching. ## Impact 1. User Experience: Significantly improves NuttX coredump debugging efficiency; users can directly get the correct crash stack via bt after loading the core file with GDB, eliminating the need to manually check and switch threads. 2. Build Process: No impact on compilation, linking, or build configuration; the modification is limited to the coredump generation logic and does not introduce new dependencies or build steps. 3. Hardware & Compatibility: Fully compatible with all existing hardware platforms supported by NuttX; no changes to hardware-related logic, and no regression in original coredump functionality. 4. Documentation & Security: No impact on official documentation; no security-related changes; maintains full compatibility with existing GDB debugging tools. 5. Core OS: No modifications to core OS scheduling, signal, or thread management functions; no side effects on system runtime behavior. ## Testing Test Environment Host Machine: Ubuntu 20.04 Target Board: NuttX-supported embedded platform (tested on BES chip-based board) Toolchain: Standard NuttX GCC toolchain Debugger: GDB for NuttX Test Steps Applied the coredump thread ordering patch to the NuttX source code. Compiled the NuttX firmware with coredump feature enabled. Deployed the firmware to the target board. Added a test case to intentionally trigger a crash in the bd_create_ui function (simulate an actual application crash). Ran the application on the target board; the system crashed and generated a valid coredump file. Used GDB to load the generated coredump file and coredump.elf. Executed the info threads command in GDB to verify the default current thread. Executed the bt command to confirm the correct crash backtrace. Test Logs text (gdb) info threads Id Target Id Frame 1 process 5 bes_idlepm () at chip/bes_idle.c:344 * 2 process 428 0x10600c72 in bd_create_ui () at bd_fps_test.c:212 Test Verification The crashed thread (process 428, bd_create_ui) is marked with * as the GDB default current thread. The default current thread matches the actual crashed thread. Running the bt command directly outputs the complete correct crash stack without manual thread switching. Executed the NuttX OS core test suite (OSTest) to confirm no functional regressions in core OS components. Verified normal coredump generation and integrity; all original thread information is preserved correctly. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
