Community
Participate
Working Groups
For breakpoints, we interrupt one thread of the target before trying to set the breakpoint. We don't do that for tracepoints because tracepoints don't actually get planted until the trace experiment is started. For fast tracepoints, it seems GDB does need to access the memory and needs to have a thread stopped to do so, even it is for the creation of the fast tracepoint. Try to set a fast tracepoint with all threads running: 314,005 [MI] 1227-break-insert --thread-group i1 -h -a -f Producer.cpp:180 314,008 [MI] 1227^error,msg="Cannot access memory at address 0x8048f6a" 314,010 [MI] (gdb) GDB failed to set the fast tracepoint. Set a slow tracepoint with all threads running 314,014 [MI] 1228-break-insert --thread-group i1 -a -f Producer.cpp:180 314,015 [MI] 1228^done,bkpt={number="15",type="tracepoint",disp="keep",enabled="y",addr="0x08048f6a\ ",func="main()",file="../src/Producer.cpp",fullname="/home/lmckhou/runtime-TestDSF/Producer/src/Prod\ ucer.cpp",line="180",times="0",original-location="Producer.cpp:180"} GDB succeeds. So, it would seem we need to take the same approach for fast tracepoints as for breakpoints, and stop one thread of the target using IMIRunControl.executeWithTargetAvailable We could do it for tracepoints in general (even though it is not strictly necessary) or we could do it just for fast tracepoints.
Even if we stop a single thread to set a fast tracepoint, a second problem arises. It seems GDB needs to select the actual stopped thread before setting the fast tracepoint. This limitation does not apply to breakpoints. For example: 1- we have process i1 with two threads running in non-stop mode 2- threads 1 is stopped and thread 2 is running 3- set a breakpoint (when sending the command to GDB we specify it is for --thread-group i1) 4- gdb sets thread-group i1 and randomly selects thread 2 (GDB seems to select the newest thread), and then successfully sets a breakpoint. however, if at step #3 we were to set a fast tracepoint, GDB would fail to set it because it would have internally selected thread 2 and it cannot set fast tracepoints while being set to a running thread. This is similar to the issue of disassembly of bug 352748. Looking at the GDB code I found this comment when it parses the --thread-group flag. /* This behaviour means that if --thread-group option identifies an inferior with multiple threads, then a random one will be picked. This is not a problem -- frontend should always provide --thread if it wishes to operate on a specific thread. */ So it looks like we need to specify a thread id in this case, the one for the stopped thread. This is a non-trivial change because we currently have tracepoints (breakpoints) assigned to a container context and not an execution context.
