Community
Participate
Working Groups
GDB supports the concepts of fast tracepoints. A fast tracepoint is a tracepoint that does not use a trap to collect the information. Instead, an instruction of the program is replaced by a jump to a the collect commands. The value of fast tracepoints is that they are very efficient and non-intrusive. The drawbacks of fast tracepoints are: 1- the program needs to be compiled with a special gdb library that supports fast tracepoints. This library takes care of modifying the program to insert the fast tracepoint jump operation 2- fast tracepoints can only be inserted at location where the opcode is at least 5 bytes to allow for a bug enough jump. DSF-GDB should make use of fast tracepoints when possible.
Here are some thoughts I've had about supporting fast tracepoints. Things to consider are: 1- gdbserver 7.2 supports fast tracepoints 2- some other remote targets may not support fast tracepoints 3- some remote targets may only allow fast tracepoints (e.g., when GDB's observer mode is enabled) 4- fast tracepoints will fail for certain locations (opcode < 5 bytes) 5- with gdbserver fast tracepoints will not be supported if the the program was not compiled with the in-process library Option 1: Always attempt to set a fast tracepoint. If it fails, then try a normal tracepoint Option 2: Have some UI to allow the user to choose between: - set a fast tracepoint only - set a normal tracepoint only - set a fast tracepoint and if it fails, set a normal tracepoint (option 1) Option 3: Have some UI to allow the user to choose between: - set a fast tracepoint only - set a fast tracepoint and if it fails, set a normal tracepoint (option 1) This could be through a preference "Create normal tracepoint when fast tracepoints cannot be set". Other aspects besides ability to set fast tracepoints: 1- special decorator showing that a tracepoints has been installed as a fast tracepoint 2- indication in editor/disassemblyView to show which lines of code support fast tracepoint
Created attachment 197146 [details] Patch for fast tracepoints and JUnit tests This patch always attempt to set a fast tracepoint and if it fails, then tries a normal (slow) tracepoint. The patch codes the service to allow for different settings: "fast then slow", "fast only", "slow only". I'm not sure we will want to present the user with such choices yet, so I'm only putting the logic in the service and defaulting it to "fast then slow".
The patch I just attach also contains the fix to Bug 347196 and the one for Bug 346215
Created attachment 197147 [details] Patch for fast tracepoints and JUnit tests 2 I noticed I had an unsaved file when I generated the previous patch. This one is correct.
Created attachment 197301 [details] Patch for fast tracepoints and multi-thread JUnit tests I updated the JUnit tests to be multi-threaded
Created attachment 198277 [details] Patch for fast tracepoints with launch preference and multi-thread JUnit tests The behavior of GDB with fast tracepoints is not what I originally thought. It turns out that creating a fast tp may succeed, but when starting the tracing experiment, installation will fail. This can happen for example: 1- if the inferior was not compiled with in-process trace library or 2- if the option 'set may-insert-fast-tracepoints' is off on the other hand, if a fast tracepoint does not fit at the chosen location, GDB will report that failure immediately: 080,054 [MI] 19-break-insert --thread-group i1 -h -a -f TracepointTestApp.cc:109 080,058 [MI] 19^error,msg="May not have a fast tracepoint at 0x0x80486c4; instruction is only 4 bytes long, need at least 5 bytes for the jump" This means that the use of a fast vs slow tracepoint depends on the support of the target, which we cannot know in advance. Therefore, I think we need to let the user choose if the launch should use fast/slow/automatic. With such a scheme, the user can create tracepoints and use them on different targets, by simply telling the launch if the tracepoints should be created fast or not on that particular target. This patch does this by adding a launch configuration combo box to the Debugger tab. As before, the patch also contains the fix to Bug 347196 and the one for Bug 346215. The patch is in git format.
Created attachment 198281 [details] Patch for fast tracepoints with launch preference and multi-thread JUnit tests 2 A small change missing for the JUnit tests to work. As before, the patch also contains the fix to Bug 347196 and the one for Bug 346215.
Created attachment 200000 [details] Patch for fast tracepoints with launch preference and multi-thread JUnit tests 3 Now that Bug 347196 and Bug 346215 have been committed, I updated the fast tracepoint patch for the latest master.
(In reply to comment #8) > Created attachment 200000 [details] > Patch for fast tracepoints with launch preference and multi-thread JUnit tests > 3 > > Now that Bug 347196 and Bug 346215 have been committed, I updated the fast > tracepoint patch for the latest master. I still don't have a way to hide the launch UI for tracepoints based on the actionSet. I will commit this patch because I would like to have it available, but I'll open a new bug for hiding the UI. So, committed to master.
Mikhail, if/when you are ever interested in looking at how GDB handles fast tracepoints, then maybe you can review this fix? Note that the biggest part of the patch are JUnit tests. The actual logic is pretty small, and simply lets the user choose in the launch if they want: 1- always use fast tp 2- always use slow tp 3- try fast tp and if it fails automatically try slow tp After that, to set a fast tp, we simply add the -h flag to -break-insert for tracepoints, and let gdb do the rest.
I've opened Bug 353040 about hiding the new "fast vs slow tracepoint" launch option
*** cdt git genie on behalf of 346320 *** Bug 346320: Add support for fast tracepoints [*] http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=d592d691aaa79832843e991734a3ef2c1a819c40
The patch seems to be OK. My only concern is that I don't see the error message in the gdb console when setting a fast tracepoint fails. It looks like a GDB problem though.
(In reply to comment #13) > The patch seems to be OK. My only concern is that I don't see the error message > in the gdb console when setting a fast tracepoint fails. It looks like a GDB > problem though. Should there be an error in the console? I created a normal breakpoint with an invalid condition, and there was no error in the console. I also tried CDI and set a breakpoint in a file not part of the debug session, and again no error in the console. I never actually thought about what should be shown as errors in the console or should not.
(In reply to comment #14) > Should there be an error in the console? I created a normal breakpoint with an > invalid condition, and there was no error in the console. I also tried CDI and > set a breakpoint in a file not part of the debug session, and again no error in > the console. > > I never actually thought about what should be shown as errors in the console or > should not. We don't write anything to the console, GDB does. In this case it looks like a GDB issue - nothing is written to the log stream and as a result doesn't appear in the GDB console. Re your example with invalid condition, I thought something would appear in the console when the breakpoint hit. If not it's a bug in GDB.
(In reply to comment #15) > We don't write anything to the console, GDB does. In this case it looks like a > GDB issue - nothing is written to the log stream and as a result doesn't appear > in the GDB console. > Re your example with invalid condition, I thought something would appear in the > console when the breakpoint hit. If not it's a bug in GDB. Right, so in both my attempts (invalid condition and invalid breakpoint file), GDB wrote nothing to the log stream. I thought that was normal...
(In reply to comment #16) > Right, so in both my attempts (invalid condition and invalid breakpoint file), > GDB wrote nothing to the log stream. I thought that was normal... I just compared the MI output for setting an invalid breakpoint and tracepoint. In case of breakpoint GDB writes the error message to the log, but it doesn't write it in case of tracepoint.
(In reply to comment #17) > (In reply to comment #16) > > Right, so in both my attempts (invalid condition and invalid breakpoint file), > > GDB wrote nothing to the log stream. I thought that was normal... > I just compared the MI output for setting an invalid breakpoint and tracepoint. > In case of breakpoint GDB writes the error message to the log, but it doesn't > write it in case of tracepoint. Just curious, what is the command you gave to see the error for breakpoints?
(In reply to comment #18) > Just curious, what is the command you gave to see the error for breakpoints? I just had a breakpoint in my workspace set on a file that wasn't in my project. In this case GDB sets a pending breakpoint and reports an error.
(In reply to comment #19) > (In reply to comment #18) > > Just curious, what is the command you gave to see the error for breakpoints? > I just had a breakpoint in my workspace set on a file that wasn't in my > project. In this case GDB sets a pending breakpoint and reports an error. You are right. Strangely, if we turn off pending breakpoints, then GDB does not write to the log for bad breakpoints: 246,497 [MI] 36-break-insert --thread-group i1 /home/lmckhou/runtime-TestDSF/Producer/src/Producer.cpp:175 246,506 [MI] 36^error,msg="No source file named /home/lmckhou/runtime-TestDSF/Producer/src/Producer.cpp." It may be that printing an error to the log for pending breakpoints is the bug.
(In reply to comment #20) > Strangely, if we turn off pending breakpoints, then GDB does not write to the > log for bad breakpoints: > > 246,497 [MI] 36-break-insert --thread-group i1 > /home/lmckhou/runtime-TestDSF/Producer/src/Producer.cpp:175 > 246,506 [MI] 36^error,msg="No source file named > /home/lmckhou/runtime-TestDSF/Producer/src/Producer.cpp." > > It may be that printing an error to the log for pending breakpoints is the bug. This is strange. I remember this message appearing in the console long before the pending breakpoints were introduced.
(In reply to comment #21) > This is strange. I remember this message appearing in the console long before > the pending breakpoints were introduced. You're right, it happens with GDB 6.8, but no longer starting with GDB 7.0. I guess they removed it.
(In reply to comment #22) > You're right, it happens with GDB 6.8, but no longer starting with GDB 7.0. I > guess they removed it. It is even stranger. Why they didn't remove it for pending breakpoints? Anyway, I think we should address the error handling of breakpoints (and tracepoints?) in the new UI for target breakpoints.
(In reply to comment #23) > (In reply to comment #22) > > You're right, it happens with GDB 6.8, but no longer starting with GDB 7.0. I > > guess they removed it. > > It is even stranger. Why they didn't remove it for pending breakpoints? Probably forgot :-) > Anyway, I think we should address the error handling of breakpoints (and > tracepoints?) in the new UI for target breakpoints. Sounds good.
