Created attachment 13963 [details] core dump Following from the fix (https://sourceware.org/bugzilla/show_bug.cgi?id=28405) for remote targets found when using a Black Magic Probe, 11.2 now has a new error when attempting to attach: thread.c:72: internal-error: thread_info* inferior_thread(): Assertion `current_thread_ != nullptr' failed. Core dump attached. I have re-confirmed that the patch in the original problem ticket works on the 11.1 branch (to make sure I wasn't going mad!) so something in the 11.2 merge has caused this? Happy to help with further info.
Hi. Thanks for the report. A gdb core file isn't super useful to us, because it is specific to your particular build of gdb. A stack trace might help more. If the bug can reliably be reproduced with some small executable and a connection to a remote, then another good option is to attach the executable and use "set remotelogfile" to capture the remote protocol trace -- this can often be replayed in gdb to reproduce the bug.
In my case executable is irrelevant, you can simply have none at all. Just need a remote debugger (I use BMP) and then as simple as $ arm-none-eabi-gdb GNU gdb (GDB) 11.2 Copyright (C) 2022 Free Software Foundation, Inc. ... For help, type "help". Type "apropos word" to search for commands related to "word". (gdb) tar ext /dev/ttyACM0 Remote debugging using /dev/ttyACM0 (gdb) mon s Target voltage: 3.29V Available Targets: No. Att Driver 1 STM32L47x M4 (gdb) set debug remote on (gdb) attach 1 Attaching to Remote target [remote] Sending packet: $vAttach;1#37 [remote] Received Ack [remote] Packet received: T05 [remote] packet_ok: Packet vAttach (attach) is supported [remote] Sending packet: $qC#b4 [remote] Received Ack [remote] Packet received: ../../gdb/thread.c:72: internal-error: thread_info* inferior_thread(): Assertion `current_thread_ != nullptr' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n)
P.S. I'm running GDB v8.2.1 in a container as of now for debug, that works ok $ podman run -i --device=/dev/ttyACM0 -v .:/home/user/cwd --group-add=keep-groups debian/buster:gdb GNU gdb (Debian 8.2.1-2+b3) 8.2.1 Copyright (C) 2018 Free Software Foundation, Inc. ... For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from bin/firmware.elf...done. Remote debugging using /dev/ttyACM0 (gdb) attach 1 Attaching to program: /home/user/cwd/bin/firmware.elf, Remote target 0x080001ec in ?? () (gdb)
> (gdb) mon s > Target voltage: 3.29V > Available Targets: > No. Att Driver > 1 STM32L47x M4 Is this special hardware? Just wondering how I'd reproduce it. > (gdb) set debug remote on Do "set remotelogfile /tmp/mumble" before the "target" command. Then, after gdb crashes, attach that log to the bug. That should be enough, I suspect, to reproduce in gdb without any special setup. Thanks.
Created attachment 14009 [details] remote log Ah, before, I forgot that part. Here it is.
And it was on Nucleo64 dev board but this is irrelevant, it's about remote protocol, not remote target. "mon s" just to demonstrate that remote target is alive.
Created attachment 14010 [details] stm32f4 remote log In case it helps move this forwards, here is a remote log of me using a Black Magic Probe attempting to attach to a STM32F4.
Created attachment 14011 [details] remote log patched working Same commands but with switch_to_thread (thread); attaches successfully and allows control of target.
Created attachment 14012 [details] patched remote add thread I had a bit of time and comparing diff of 11.1 with patch in original ticket, the combination of `add_thread_silent` into `remote_add_thread` for bare metal targets incorrectly orders the `switch_to_thread` call and the setting of the thread states `set_thread..`. I'll be honest I don't fully understand the thread methods here, but this is what appears to be the case and fixes the issue. I assume the `switch_to_thread` makes the phony thread real?
yyyeeess!!!! it's work fine! finally, you can assemble the otadchik from the trunk and test everything new! I am about twice a week rebuilding all the tools and libraries from the trunk and studying the errors of new features, sometimes I can help fix them. But with this error, I could not do anything, it appeared in the trunk in October. John Whittington, you are the best :), thank you so much! maybe this is a crutch and something will break if the processor has two cores or there will be another target, but here and now it works! klen@klen-station:/klen/home/arm-kgp-eabi_@_x86_64-kgp-linux-gnu_znver3_avx2$ arm-kgp-eabi-gdb GNU gdb (Klen's_GNU_package_(KGP)_for_target::arm-kgp-eabi<rmprofile/lto>_host::x86_64-kgp-linux-gnu<<OXALIS>>) 12.0.50.20220315-git Copyright (C) 2022 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "--host=x86_64-kgp-linux-gnu --target=arm-kgp-eabi". Type "show configuration" for configuration details. For bug reporting instructions, please see: <klen_s@mail.ru>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word". (gdb) tar ext /dev/kgp/bmp Remote debugging using /dev/kgp/bmp (gdb) mon s Target voltage: 0.0V Available Targets: No. Att Driver 1 STM32H7 M7 (gdb) att 1 Attaching to Remote target 0x0800bb2e in ?? ()
Created attachment 14022 [details] patched remote add thread Glad to hear the fix works for you too and the kind words :). How do we get this patch into the next release? I've updated diff with ChangeLog updated and matched formatting. Whilst it is a bit of the hack for the silent_p flag, looking at the 11.1 diff, that flag was added solely for non-threaded targets like the BMP. Should it be sent to mailing list?
Despite the fact that I am also a little in kurma how it all works, I can not say anything definitively. Due to the fact that microcontrollers sometimes began to have more than one core, a situation arose that the infrastructure for remote debugging should be fundamentally expanded ( cpu cores, multithreading etc ), probably not done with just skewers and patches. Judging by the code 11.1 - it works correctly but "in the old way". In 11.2, they started trying to fix it and broke everything :) It will probably take a lot of work to make it elegant and reliable again on different targets I tried your changes on trunk code - it also fixes the problem... but unfortunately gdb now crashes when communicating via MI protocol with eclipse IDE. in the console everything is fine and correctly debugged.
> How do we get this patch into the next release? I've updated diff with > ChangeLog updated and matched formatting. Whilst it is a bit of the hack for > the silent_p flag, looking at the 11.1 diff, that flag was added solely for > non-threaded targets like the BMP. Should it be sent to mailing list? ChangeLogs are gone now, fwiw. Anyway, gdb patches are usually reviewed on the gdb-patches list. See https://sourceware.org/gdb/wiki/ContributionChecklist
Created attachment 14040 [details] added has_inferior_thread() and checks it in remote_add_thread() > Whilst it is a bit of the hack for > the silent_p flag, looking at the 11.1 diff, that flag was added solely for > non-threaded targets like the BMP. I don't fully understand the thread methods here either, but `extended_remote_target::attach()` calls `switch_to_inferior_no_thread()` before calling `remote_add_thread()` for any target where `target_is_non_stop_p() == false`, with no `switch_to_thread()` in-between, so I think this bug might affect more than just non-threaded targets? I would be interested to know if any other targets are experiencing this bug, but either way if you'd like a less hacky and possibly more general-case solution for this, then that might just be to check in `remote_add_thread()` if there is a current thread or not, and switch if not, as in this patch? This patch does create more diff-noise, though; I'm not sure which is preferable for gdb.
Do you ever get any feedback Mikaela (patch works for me)? If it doesn't break any tests it would be good to try and get this merged.
I have not. I have even bumped the patch thread asking if there are any questions about the patch (https://sourceware.org/pipermail/gdb-patches/2022-June/190342.html), but it has not received any responses. If there are any maintainers watching this bug I'd love to know if there's anything I can do to help get this patch merged.
The Black Magic Probe firmware has now been updated to support fake threads rather than waiting/hoping for a fix in GDB for this: https://github.com/blackmagic-debug/blackmagic/pull/1125
Is this an issue with using thread/process 0 as identifier?
I run into this same issue on the latest version of gdb (13.2 at the time of writing) and gdbserver when debugging various remote 32-bit ARM targets, specifically when using pwndbg loaded (sets up various event hooks). Also worth noting that after gdb crashes, if you restart gdb and re-attach a second time without restarting the target process, the attach works correctly. My solution has always been to just automatically restart gdb on crash and re-attach from a shell script. I've confirmed that using the patch provided by John Whittington addresses the problem. Would be nice to get this fixed as pwndbg users wishing to remotely debug an ARM target will run into this issue. Happy to provide any debug information needed.