Multicore Gdb: Thread 2 hang on breakpoint infinitely (no cache)

[hananyasegal1]

When working on multicore, both threads have different BPs in different locations.
Both threads are at a breakpoint simultaneously. However, the GDB sees only the '$T05thread:1;#d7' packet, although thread 2 is also at the breakpoint.
Thread 1 continues as expected from his BP, whereas thread 2 hangs on his BP on the 'resuming' or 'single-step' commands.
There is no cache in the system at all.
It seems the GDB client is not aware that thread 2 is at BP.

[TommyMurphyTM1234]

You'll probably need to provide more information such as...

1. The version of OpenOCD that you're using (if it's not a build of the latest sources in this repo then you should try that first).
2. What OpenOCD scripts you're using to connect to your target.
3. A verbose openocd -d3 log for your debug session (capture, compress if necessary, and attach this - don't copy and paste it into the editor please).

[hananyasegal1]

Hi @TommyMurphyTM1234 ,

1. It happens on the latest version, too.
2. Attached openocd.cfg.txt configuration file.
3. Attached openocd_bp_thread_2_problem.txt and gdb.txt log file too.

openocd.cfg (1).txt
openocd_bp_thread_2_problem.txt
gdb.txt

Thanks,
Hananya

[aap-sc]

@hananyasegal1

it's not quite clear what is wrong from your description.

What do you mean by ' (no cache) ' ?

In addition to the information requested by @TommyMurphyTM1234 , would you kindly attach:

1. an .elf image if possible. If this file contains sensitive information, please try to minimize the reproduction since the presence of the original image will help with analysis.
2. please do proper recording of the remote serial protocol. This can be done with set remotelogfile gdb.remote.log. Again, make sure that there is no IP-sensitive information in the log.

[hananyasegal1]

Hi @aap-sc,

The meaning of 'no-cache' is that we have disabled the cache memory at all.
Meaning that the root cause cannot be the cache incoherency.

Thanks,
Hananya

[hananyasegal1]

Hi @JanMatCodasip,

We are using the SMP mode, single GDB instance.

Thanks,
Hananya

[hananyasegal1]

Hi,

Attached test.txt file.
Please change the ending to elf.

Thanks,
Hananya

[Hershkyman]

Hi Following on the same issue, I work with hananyasegal1,
We are debugging 2 threads that both halted on breakpoint.

1st thread is on focus on the gdb, and we execute continue, when the scheduler-lock is off, so both can run.
Only the 1st thread was able to run pass the breakpoint, since the breakpoint for his thread was removed and stepped.
The 2nd thread wasn't handled (gdb returned his breakpoint when he handled the continue).

We tried sending a later reply of t05thread:2; after the continue as to add another handling for the 2nd thread, but it didn't help.

We see that after changing the focus to the 2nd thread, the next continue command will cause the removal of the 2nd thread breakpoint so it can step and continue afterwards.

My question is - in smp mode, when both threads are simultaniously in a break, can we make both threads continue and not only the one in focus?