Community
Participate
Working Groups
With GDB 7.5 GDB introduced the concept of a Dynamic Printf. It is a kind of breakpoint which prints a string and resumes the program automatically. This allows users to add "printf" statements to their code without needing to recompile and re-deploy. With GDB's set disconnected-dprintf on|off dynamic printfs can even remain if GDB disconnects from the program; this is even more like adding a printf in the program. I suggest supporting this feature by adding a new type of breakpoint just like was done for Tracepoints.
I've pushed a preliminary patch to gerrit. It is not complete but if someone wants to try it, they can, things are very close to done. https://git.eclipse.org/r/10746 A couple of things still need to be added: 1- support changing the dprintf string from the breakpoint properties 2- support disconnected dprintf 3- maybe disable conditions for dprintf since they are broken in GDB: http://sourceware.org/bugzilla/show_bug.cgi?id=15179 http://sourceware.org/bugzilla/show_bug.cgi?id=15180 4- Write JUnit tests
Oh, and I need an icon for a dprintf breakpoint. What kind of 'decoration' means "print"? Anyone?
Interesting improvements/fixes are being proposed for dynamic-printf in GDB: http://sourceware.org/ml/gdb-patches/2013-02/msg00736.html Let's see how that moves forward as we may choose to only support to improved GDB implementation.
Since feature freeze in this coming Monday and I would like to provide this feature for Kepler instead of having to wait an entire extra year, I propose that I quickly clean up the feature in the next couple of days enough that it will be functionally complete. I will then commit the feature to make feature freeze. In the remaining month, we can go through review, comments and further cleanup. If for some reason we find the feature is not good enough for the Kepler release, we can pull it out, or simply turn if off completely. But I'm hoping that all we'll need is to address comments and tweak a couple of things. Please let me know if anyone objects to this approach.
I've pushed a new version to Gerrit that I feel is complete enough. I will continue running some tests before committing. Missing aspects are: - Support disconnected dprintf - JUnit tests I've decided to keep supporting conditions for dynamic printf although they are currently broken in GDB: http://sourceware.org/bugzilla/show_bug.cgi?id=15179 http://sourceware.org/bugzilla/show_bug.cgi?id=15180 The reason is that once they are fixed in a newer version of GDB, they should be supported in CDT, and if we turn them off now, we'll need to wait until next year to re-enable them, although the new GDB will be out much before that.
I'm sad to say that after testing and much effort, I've decided not to commmit this for Kepler :( I'm happy with the Eclipse implementation, but I'm hitting too many bugs in GDB's current support for dynamic-printf. I'm worried that making this available in Kepler will give a poor user experience and will turn users off to using dynamic-printf. I'm expecting the support to be much better in GDB 7.7, which would give CDT a nice user experience. The most important issues I ran into were: 1- GDB uses 'continue' to automatically resume after hitting a dprintf. This is a synchronous continue instead of the asynchronous '-exec-continue' (or 'continue&') that CDT expects. What that means is that as soon as a dprintf is hit, CDT can no longer contact GDB (as if it were in all-stop mode) and the entire debug session become unresponsive to any user action. http://sourceware.org/bugzilla/show_bug.cgi?id=15434 2- Each time a dprintf is hit by GDB, it sends a blank '*stopped' event followed by a '*running' event. That blank '*stopped' event seems to be causing problems because it is not associated to a process or thread; CDT therefore goes into an invalid state where it wrongly thinks all threads are stopped. I'm seeing different kinds of unexpected behaviors of CDT, which I believe are caused by this. 123,776 [MI] *stopped 123,776 [MI] *running,thread-id="1" 123,780 [MI] =breakpoint-modified,bkpt={number="5",type="dprintf",... I can probably work around this, but I'm worried it could break other situations where we've seen a blank '*stopped' event. I would need more time to test and soak such a fix. The above two are the problems that are making me not want to support dprintf with GDB 7.5 or 7.6, but instead wait for GDB 7.7. Below are other issues that I didn't feel were show-stoppers, but would still give a much reduced user-experience. 3- It is not possible to step over a dprintf in GDB http://sourceware.org/bugzilla/show_bug.cgi?id=15075 4- Conditions are not respected in GDB http://sourceware.org/bugzilla/show_bug.cgi?id=15179 http://sourceware.org/bugzilla/show_bug.cgi?id=15180 5- Ignore-count is not respected in GDB 7.5 (although fixed in 7.6) http://sourceware.org/bugzilla/show_bug.cgi?id=15293 6- For remote sessions, dprintf output is not flushed as expected in GDB 7.5 (although fixed in 7.6) http://sourceware.org/bugzilla/show_bug.cgi?id=15186 7- Pending dprintf don't work in GDB 7.5 (although fixed in 7.6) http://sourceware.org/bugzilla/show_bug.cgi?id=15292 Considering all these issues and the fact that we're so late in the release cycle, I don't feel it is safe to commit this feature. I plan on following GDB's progress in fixing these issues, and then adding this feature as early as possible in Luna, to give it more soak time.
Created attachment 230518 [details] DPrintf current icon (In reply to comment #2) > Oh, and I need an icon for a dprintf breakpoint. What kind of 'decoration' > means "print"? Anyone? AS a side note, I've come up with a new icon, based on Mikhail's suggestion. I've attached it for those curious. It is not as professional as I'd like it to be, but I think it is a better start. I can always be improved or changed, if we get our hands on a better one.
I've pushed patchset 3 to Gerrit. This change adds two things: 1- work around a GDB crash: http://sourceware.org/bugzilla/show_bug.cgi?id=15433 2- disable breakpoint synchronization for dprintf, since it is not currently behaving as expected due to bug 407330 I'm going to leave things as is for now and wait for GDB to make progress. When that happens, I can update the feature to use the latest dprintf interface as provided by GDB.
I've pushed Patchset 7 to gerrit: - updated patch for GDB 7.7 which provides an MI command '-dprintf-insert' - only allow dprintf in CDT using GDB 7.7 which is more stable - add support for dprintf for the GDB Hardware launch. For some reason the 'call' style which prints to stdout does not work in this mode. I will investigate this further with GDB but for now, I set it to 'gdb' style, which will dprintf to the gdb console. I'm having an issue with dprintf being set multiple times with multi-process. This is bug 389945 which I will look at now.
Hi Marc. I tried to use dprintf today while debugging Eclipse (SWT/GTK3 bug on Ubuntu). Using GDB 7.7 that I compiled myself on Ubuntu 13.10 64 bit. After I inserted the dprintf breakpoint, both my process and gdb seemed to be hung (gdb was using all of one CPU). The printf in my breakpoint is: "Hit line %d of /media/mark/SourceCode1310/overlay-scrollbar/overlay-scrollbar-0.2.16+r359+13.10.20130826/os/os-bar.c\n",850 (I left it as the default) When I restarted the Debug session, I got a few error message in the gdb console (not traces): Error in re-setting breakpoint 1: Format string required and the breakpoint wasn't "checked" so I assume it wasn't re-inserted properly. I'm attaching both gdb traces of before and after restart. I'm not sure how widespread those two problems are but I though I should let you know.
Created attachment 241633 [details] gdb traces for first session
Created attachment 241634 [details] gdb traces after restart
I forgot to mention that I had multi-process and non-stop enabled.
I had this in my .gdbinit: handle SIGSEGV nostop noprint If I change it to: handle SIGSEGV nostop then it works. I also tested that with a simple hello world program and got an internal error from gdb (both 7.7 and master): 511,456 *stopped,reason="exited-signalled",signal-name="SIGSEGV",signal-meaning="Segmentation fault"\ 475,861 ~"thread.c:85: internal-error: inferior_thread: Assertion `tp' failed.\nA problem internal t\ o GDB has been detected,\nfurther debugging may prove unreliable.\nQuit this debugging session? " Then I tried to reproduce this on the command line but strangely, it doesn't matter if I do 'handle SIGSEGV nostop noprint' or not, it always triggers the SIGSEGV. I created this bug: https://sourceware.org/bugzilla/show_bug.cgi?id=16812
(In reply to Marc-Andre Laperle from comment #14) > I had this in my .gdbinit: tried to reproduce this on the command line but strangely, it doesn't > matter if I do 'handle SIGSEGV nostop noprint' or not, it always triggers > the SIGSEGV. I created this bug: > https://sourceware.org/bugzilla/show_bug.cgi?id=16812 Correction, it does make a difference how SIGSEGV is handled. I forgot I had a .gdbinit in my home directory that contained such a line.
Patchset 12 is ready for review: https://git.eclipse.org/r/#/c/10746/ Major points: - Requires GDB 7.7. Only works with DSF. - A dynamic-printf is a new type of breakpoint - It can be installed like a normal breakpoint once its bp type is selected using the editor's margin menu - The Editor and Disassembly view have a "Add dynamic-printf..." menu which allows to create a dynamic-printf no matter which bp type is selected. The idea is to make this feature visible to users. - when a dprintf is set, its printf string will print to the same location as any other printf (in eclipse for a local session, in the console where the process was started for an attach, etc) - 'skip all breakpoints' does not affect dprintf (the icon still shows the strike through, I will address this separately as it also affects Tracepoints) Known problems: - synchronization with gdb console is broken because MI events sent by GDB have errors in their escaping. We are trying to get that fixed in GDB. The impact is that: 1- a dprintf created from the console will not show the proper string in eclipse 2- a dprintf modified from the console to use a different printf string will not show the proper string in eclipse - synchronization of function dprintf does not work - each time a dprintf is hit by GDB, a =breakpoint-modified is sent. This can cause eclipse to become very slow if we put a dprintf in a tight loop (which probably should be avoided anyway). I am working at getting that event removed in GDB. The patch is very large (3500 lines) but is largely based on the Tracepoint support that has been part of CDT for 4 years. I'm hoping to commit this before feature freeze on May 9th. I will now work on adding JUnit tests to cover the changes to the services for dprintf.
Because feature freeze is Monday, we agreed to commit this now. Any issues found in a later review will be addressed then. I still plan on writing JUnit tests for this. Committed to master from Gerrit.
A user using GDB 7.6 which according to GDB supports dprintf was presented with a warning and the dprintf didn't work. I would like to improve the warning message in this case. Gerrit on the way. See http://stackoverflow.com/questions/42644497/eclipse-cdt-dynamic-printf-feature-not-working/42650865#42650865
New Gerrit change created: https://git.eclipse.org/r/92511
Gerrit change https://git.eclipse.org/r/92511 was merged to [master]. Commit: http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=87c75513e07744deb75dd7c025422854094831cc
BTW, should this bug be marked as fixed?
This feature has been released quite a while ago.