Feature: fake thread support #1125

dragonmux · 2022-07-20T05:03:40Z

This PR addresses the issue that the GDB folks have blown us off once again and refuse to fix GDB to support targets (and therefore GDB servers) which simply can't have threads.

In this PR we implement support for the machinery GDB uses for threads support, but only to fake there being a single thread in any given "process" (debug port on the scan chain). This has the side effect of requiring the implementation of such things as vKill otherwise GDB 11 and newer won't actually execute a process kill as they don't use the old method.

This will need merging to both main and v1.8

This fixes #929

dragonmux · 2022-07-20T06:47:45Z

Update: GDB 12 is now tested and confirmed working

tuna-f1sh · 2022-07-20T08:51:28Z

I gave this a quick try to help move this along but didn't go so well. Both load and continue result in errors. monitor commands seem to work:

(gdb) load
Remote target does not support flash erase
(gdb) set debug remote on
(gdb) load
[remote] Sending packet: $vFlashErase:08000000,0000c000#f5
[remote] Received Ack
[remote] Packet received:
Remote target does not support flash erase
(gdb) mon s
[remote] Sending packet: $qRcmd,73#8d
[remote] Received Ack
[remote] Packet received: O54617267657420766f6c746167653a20332e33560a
Target voltage: 3.3V
[remote] Packet received: O417661696c61626c6520546172676574733a0a
Available Targets:
[remote] Packet received: O4e6f2e20417474204472697665720a
No. Att Driver
[remote] Packet received: O203120202020202053544d333246343078204d340a
 1      STM32F40x M4
[remote] Packet received: OK
(gdb) c
Continuing.
[remote] Sending packet: $vCont?#49
[remote] Received Ack
[remote] Packet received:
[remote] packet_ok: Packet vCont (verbose-resume) is NOT supported
[remote] Sending packet: $Hc0#db
[remote] Received Ack
[remote] Packet received: OK
[remote] Sending packet: $c#63
[remote] Received Ack
[remote] wait: enter
  [remote] Packet received: X1D
  [remote] select_thread_for_ambiguous_stop_reply: enter
    [remote] select_thread_for_ambiguous_stop_reply: process_wide_stop = 1
    [remote] select_thread_for_ambiguous_stop_reply: first resumed thread is Thread 1
    [remote] select_thread_for_ambiguous_stop_reply: is this guess ambiguous? = 0
  [remote] select_thread_for_ambiguous_stop_reply: exit
[remote] wait: exit

Program terminated with signal SIGLOST, Resource lost.
The program no longer exists.
[remote] Sending packet: $qfThreadInfo#bb
[remote] Received Ack
[remote] Packet received: m1
[remote] Sending packet: $qsThreadInfo#c8
[remote] Received Ack
[remote] Packet received: l
[remote] Sending packet: $qAttached#8f
[remote] Received Ack
[remote] Packet received:
[remote] packet_ok: Packet qAttached (query-attached) is NOT supported
[New Thread 1]
[remote] Sending packet: $Hg1#e0
[remote] Received Ack
[remote] Packet received: OK
[remote] Sending packet: $g#67
[remote] Received Ack
[remote] Packet received: EFF
Could not read registers; remote failure reply 'EFF'
(gdb) monitor tpwr enable
[remote] Sending packet: $qRcmd,7470777220656e61626c65#07
[remote] Received Ack
[remote] Packet received: O456e61626c696e672074617267657420706f7765720a
Enabling target power
[remote] Packet received: OK
(gdb)

dragonmux · 2022-07-20T09:39:09Z

Thank you for testing this. Interesting that particularly continue results in such a failure - we think we might know why but that's going to take some more diving the GDB code to fix. We'll look into it after we've had some sleep.

Load is the more curious one as we can't see why that'd not work (as vFlashErase is how BMP works for this).. smells like more protocol shenanigans that they've not documented

dragonmux · 2022-07-20T20:44:40Z

ah @tuna-f1sh in the trace above, you never run att 1 to attach into the target - this is why continue fails (correctly).

Given scanning the bus implies 'kill', we'll see if when running such a command with an active target being disconnected from.. we can generate a packet to GDB that tells it that it's not attached any more

…ngs up

dragonmux · 2022-07-20T22:33:12Z

We've done what we can to make the sequence of events above more obvious that you've not attached after doing a bus scan.. including trying to notify GDB that "the process has exited" with a Stop notification.. but GDB seems to implement it's own remote protocol wrong there so shrugs but we tried.

We tested continue works on our test target with GDB 11 and it does when actually attached. We'll dive into load if you could re-check that you were actually attached to the target

esden

Thank you very much for implementing this workaround. I am still disappointed that the GDB developers are having so much trouble wrapping their head around the problem they introduced.

I am merging it for now to make our users life easier.

esden · 2022-07-21T03:43:01Z

Ok, I think I was a bit too trigger happy on the review. I am testing with GDB 12.1 and I am getting an error trying to flash firmware:

GNU gdb (GDB) 12.1
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-pc-linux-gnu --target=arm-none-eabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
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"...
Reading symbols from /home/esdentem/projects/1bitsy/1bitsy-examples-git/examples/1bitsy/pwmledfade/pwmledfade.elf...
(gdb) tar ext /dev/ttyBmpGdb
Remote debugging using /dev/ttyBmpGdb
(gdb) mon s
Target voltage: 3.3V
Available Targets:
No. Att Driver
 1      STM32F40x M4
(gdb) att 1
Attaching to program: /home/esdentem/projects/1bitsy/1bitsy-examples-git/examples/1bitsy/pwmledfade/pwmledfade.elf, Remote target
0x0800039c in main () at pwmledfade.c:167
167			for (i = 0; i < 200000; i++) asm("nop");
(gdb) load
Remote target does not support flash erase
(gdb)

Found a problem with the "load" command.

dragonmux · 2022-07-21T04:10:21Z

The load command issues should now be resolved after examining the protocol trace you gave us in Discord. Please try again now :)

…nally broken otherwise

… attached that you aren't after the command, despite what GDB thinks

…ited when the user runs a new bus scan while attached to a target

esden

Tested on native hardware with STM32F4 target using GDB 12. The following things were tested:

attach
load
start
next/step
break/watch
continue

So I will call it good. Let's see what happens ;) :D

tuna-f1sh · 2022-07-21T06:59:40Z

@dragonmux I'll tested the updated but just to clarify, I'm fairly sure I was attached (scan, attach is part of my workflow) just it wasn't capture in pasted. The mon s did say however (right before continue):

No. Att Driver
[remote] Packet received: O203120202020202053544d333246343078204d340a
 1      STM32F40x M4"

Which means the STM32F4 was attached?

dragonmux · 2022-07-21T07:17:29Z

That output means the STM32F4 was found but there's no * in the attach column - you must run att 1 after to attach. (scanning will never attach even if there's only one target, fwiw - this is a protocol limitation)

esden · 2022-07-21T07:39:12Z

@tuna-f1sh You might want to refer to the documentation. https://black-magic.org/getting-started.html#connecting-to-the-software there is also a video that walks you through the basics of how to use Black Magic Probe.

tuna-f1sh · 2022-07-21T08:16:05Z

@esden @dragonmux thanks for the link but I've been happily using it for years so must have just made an oversight quickly testing that firmware (I have an attach script and think maybe the device wasn't powered or something and I forgot after mon tpwr enable) - I tested that previous commit and it works so sorry for the false report.

Anyway, glad both issues are now closed 🥳

bonidydy · 2022-07-21T18:27:57Z

Getting the same error as tuna-f1sh with continue on gdb 12.1:

(gdb) c
Continuing.

Program terminated with signal SIGLOST, Resource lost.
The program no longer exists.
[New Thread 1]
Could not read registers; remote failure reply 'EFF'
Cannot execute this command without a live selected thread.

And yes - it was attached.

dragonmux · 2022-07-21T18:37:13Z

The behavior you're seeing can occur for exactly two reasons:

			if (!cur_target) {
				gdb_putpacketz("X1D");
				break;
			}

and

			case TARGET_HALT_ERROR:
				gdb_putpacket_f("X%02X", GDB_SIGLOST);
				morse("TARGET LOST.", true);
				break;

The latter will make the LEDs on BMP blink in a morse-code pattern.
In the former case it's because you re-ran scan or similar without doing an attach after, the latter indicates a possible bug.

Please open a new issue with a trace of what you're doing. In the case of LEDs blinking, please try building the firmware with ENABLE_DEBUG=1, running mon debug en immediately after connecting to BMP and monitoring the debug USB UART, providing the output to help us figure out what's going wrong. If you're using the project's udev rules that can be accomplished by running minicom -D /dev/ttyBmpTarg -8

bonidydy · 2022-07-23T08:55:19Z

Hmm... I cannot reproduce it now and earlier was getting it all over again. And indeed happens only when detached after repeated scan.

tuna-f1sh · 2022-07-23T12:01:24Z

@bonidydy yeah I played around after this and think it’s the repeated ‘mon s’ I did as part of the bug capture (following ‘load’ fail bug), which I wouldn’t normally do and didn’t realise detached any attached.

…fake thread support). Merge support for hardware version 6 (BMP v2.3) from release 1.8.2. Merge partial Flash memory locking for SAMD devices from 1.8.2. Replace some calls to alloca() to calloc(). Code clean-up (mostly merged from release 1.8.2).

dragonmux added Bug Confirmed bug GDB Issue/PR related to GDB labels Jul 20, 2022

dragonmux requested a review from esden July 20, 2022 05:03

dragonmux mentioned this pull request Jul 20, 2022

GDB 11/12 compatibility #929

Open

dragonmux added this to the v1.8.2 bugfix release milestone Jul 20, 2022

dragonmux added 2 commits July 20, 2022 22:04

gdb_packet: Done a spring pass on the types situation and cleaned thi…

12caf1a

…ngs up

gdb_main: Implemented H[m|M|g|G|c] packet support

f62b5af

dragonmux force-pushed the feature/fake-thread-support branch 2 times, most recently from 9dba098 to 9501e44 Compare July 20, 2022 21:49

esden previously approved these changes Jul 21, 2022

View reviewed changes

dragonmux force-pushed the feature/fake-thread-support branch from 133da84 to 0c679f9 Compare July 21, 2022 04:09

dragonmux added 10 commits July 21, 2022 05:24

gdb_main: More type confusion fixes and cleanup

42e1890

gdb_main: Implemented support for qC queries

c9c423a

gdb_main: Reply to vAttach with TID 1 because GDB 11 and 12 are termi…

f7d90e6

…nally broken otherwise

hex_utils: Cleaned up and fixed the type confusion that was going on

da6116c

gdb_main: Cleaned up the naming in the 'g' and 'G' packet handlers

e26cc6a

gdb_main: Implemented vKill as it's required for GDB 11+

597dc92

gdb_main: Implemented qfThreadInfo and qsThreadInfo for GDB 11+

bed4e5d

gdb_main: Add some output in the scan commands to indicate when still…

4b9a652

… attached that you aren't after the command, despite what GDB thinks

gdb_packet: Implement notification packets

3e1b33e

gdb_main: Implemented a notification to GDB that the "process" has ex…

ee78325

…ited when the user runs a new bus scan while attached to a target

dragonmux force-pushed the feature/fake-thread-support branch from 0c679f9 to ee78325 Compare July 21, 2022 04:24

esden approved these changes Jul 21, 2022

View reviewed changes

esden merged commit e2f07b3 into main Jul 21, 2022

dragonmux deleted the feature/fake-thread-support branch July 21, 2022 04:40

dragonmux mentioned this pull request Jul 21, 2022

gdb_main: Fixed a small DEBUG_GDB regression for vFlashErase and vFlashWrite debugging #1127

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Feature: fake thread support #1125

Feature: fake thread support #1125

dragonmux commented Jul 20, 2022 •

edited

Loading

dragonmux commented Jul 20, 2022

tuna-f1sh commented Jul 20, 2022

dragonmux commented Jul 20, 2022

dragonmux commented Jul 20, 2022 •

edited

Loading

dragonmux commented Jul 20, 2022

esden left a comment

esden commented Jul 21, 2022

dragonmux commented Jul 21, 2022

esden left a comment •

edited

Loading

tuna-f1sh commented Jul 21, 2022 •

edited

Loading

dragonmux commented Jul 21, 2022 •

edited

Loading

esden commented Jul 21, 2022

tuna-f1sh commented Jul 21, 2022

bonidydy commented Jul 21, 2022

dragonmux commented Jul 21, 2022

bonidydy commented Jul 23, 2022

tuna-f1sh commented Jul 23, 2022

Feature: fake thread support #1125

Feature: fake thread support #1125

Conversation

dragonmux commented Jul 20, 2022 • edited Loading

dragonmux commented Jul 20, 2022

tuna-f1sh commented Jul 20, 2022

dragonmux commented Jul 20, 2022

dragonmux commented Jul 20, 2022 • edited Loading

dragonmux commented Jul 20, 2022

esden left a comment

Choose a reason for hiding this comment

esden commented Jul 21, 2022

dragonmux commented Jul 21, 2022

esden left a comment • edited Loading

Choose a reason for hiding this comment

tuna-f1sh commented Jul 21, 2022 • edited Loading

dragonmux commented Jul 21, 2022 • edited Loading

esden commented Jul 21, 2022

tuna-f1sh commented Jul 21, 2022

bonidydy commented Jul 21, 2022

dragonmux commented Jul 21, 2022

bonidydy commented Jul 23, 2022

tuna-f1sh commented Jul 23, 2022

dragonmux commented Jul 20, 2022 •

edited

Loading

dragonmux commented Jul 20, 2022 •

edited

Loading

esden left a comment •

edited

Loading

tuna-f1sh commented Jul 21, 2022 •

edited

Loading

dragonmux commented Jul 21, 2022 •

edited

Loading