Community
Participate
Working Groups
When pressing the start tracing button in the TraceControl view, it is possible that GDB will reject the request. In that case, the buttons are not properly refreshed and their enablement is wrong. For example, if I try to start tracing but I didn't create tracepoints: 398,325 [MI] 93-trace-start 398,326 [MI] 93^error,msg="No tracepoints defined, not starting trace" We need to be prepared for such a failure.
*** cdt git genie on behalf of 352493 *** Bug 352493:Trace control buttons are disabled after a start trace failure [*] http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=163a57b8b7ea789cbec84e578c9992243579767a
*** cdt git genie on behalf of 352493 *** Bug 352493:Trace control buttons are disabled after a start trace failure [*] http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=cbffe1484b064cb5b971ed0a3887f6c4b5f0be82
Created attachment 199936 [details] Fix When getting an ^error after a -trace-start, we now trigger an event to refresh the button to the current state of tracing. Committed to master and 8_0
Fixed. Mikhail, can you review?
(In reply to comment #4) > Fixed. > Mikhail, can you review? I'll try. What do I need to use tracepoints? Can you point me to a wiki page is there is one?
(In reply to comment #5) > (In reply to comment #4) > > Fixed. > > Mikhail, can you review? > > I'll try. What do I need to use tracepoints? Can you point me to a wiki page is > there is one? There is an outdated wiki page at http://wiki.eclipse.org/CDT/designs/Tracepoints but it does not contain everything and some things have not been implemented. I've been meaning to write a new FAQ section for Tracepoints. I'll try to do it this week and let you know when it is available.
(In reply to comment #6) > I've been meaning to write a new FAQ section for Tracepoints. I'll try to do > it this week and let you know when it is available. That was the motivation I needed: http://wiki.eclipse.org/CDT/User/FAQ#How_can_I_trace_my_application_using_C.2FC.2B.2B_Tracepoints.3F I hope it is clear enough. Please let me know, as a user, if you find something confusing.
Marc, It seems that I'm doing everything according to your instructions, but the actions in the trace control are always disabled. The reason is the "trace-status" command always returns "supported=0". I am using gdb 7.2, is there anything else I should do to make tracing available?
(In reply to comment #8) > Marc, > It seems that I'm doing everything according to your instructions, but the > actions in the trace control are always disabled. The reason is the > "trace-status" command always returns "supported=0". I am using gdb 7.2, is > there anything else I should do to make tracing available? Thanks for trying Mikhail. Did you run a remote session using gdbserver? Tracing is not supported in GDB with a local session.
(In reply to comment #9) > Did you run a remote session using gdbserver? Tracing is not supported in GDB > with a local session. Yes, I'm using Remote Launcher with RSE. I can set tracepoints, but can not start tracing.
(In reply to comment #10) > (In reply to comment #9) > > Did you run a remote session using gdbserver? Tracing is not supported in GDB > > with a local session. > > Yes, I'm using Remote Launcher with RSE. I can set tracepoints, but can not > start tracing. Are you running on linux? Windows won't work. If you get "supported=0" it is GDB that can't trace. Try running just GDB like this: > gdbserver.7.2 :9999 a.out > gdb.7.2 a.out [...] (gdb) target remote :9999 Remote debugging using :9999 Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/ld-linux.so.2 0x00686850 in ?? () from /lib/ld-linux.so.2 Created trace state variable $trace_timestamp for target's variable 1. (gdb) interpreter-exec mi "-trace-status" ^done,supported="1",running="0",frames="0",frames-created="0",buffer-size="5242880",buffer-free="5242880",disconnected="0",circular="0" I get "supported=1"
Thanks Marc. I didn't set the right path and it was starting an old version of gdbserver. It is working now.
Marc, your fix works fine for this particular issue, but I have a couple of questions. 1.Wouldn't it be better to disable "Start Tracing" when there is no tracepoints set? 2."Start Tracing" remains enabled when the trace is running. Is it intentional? I also found an unrelated bug - most of the Debug view actions (Resume, Step, etc.) remain disabled when switching from "visualization" mode back to "debug" mode. Seems the Debug view needs to be refreshed, selecting anything in it enables the actions. Just want to check with before creating a bugzilla for it.
(In reply to comment #13) > Marc, your fix works fine for this particular issue, but I have a couple of > questions. I'm glad you got it working. It is nice that at least two of us can set it up :-) > 1.Wouldn't it be better to disable "Start Tracing" when there is no tracepoints > set? I never thought about it before. It is a good idea but I wonder how valuable it will be. If there is any tracepoint defined in the workspace, even for another project/target, that tracepoint will be marked as pending for the current debug session, and "Start tracing" will need to be enabled. So, the only time we could turn off "Start tracing" is if there are no tracepoints defined in the workspace. If you find it is something a user would expect, then we can do that. Can we make that a new bug? > 2."Start Tracing" remains enabled when the trace is running. Is it intentional? If you change/add/delete a tracepoint, it does not affect the running trace experiment. To get those changes to apply, one needs to restart the tracing experiment. You can do that without stopping the experiment, that is why "start tracing" stays enabled. Note that you will loose any collected data when you do that. > I also found an unrelated bug - most of the Debug view actions (Resume, Step, > etc.) remain disabled when switching from "visualization" mode back to "debug" > mode. Seems the Debug view needs to be refreshed, selecting anything in it > enables the actions. Just want to check with before creating a bugzilla for it. I have added a fix for that in Bug 347514, which I should be committing soon, I hope. If you have any more suggestions for usability of C/C++ Tracpoints, please don't hesitate.
(In reply to comment #14) > > 1.Wouldn't it be better to disable "Start Tracing" when there is no tracepoints > > set? > > I never thought about it before. It is a good idea but I wonder how valuable > it will be. If there is any tracepoint defined in the workspace, even for > another project/target, that tracepoint will be marked as pending for the > current debug session, and "Start tracing" will need to be enabled. > > So, the only time we could turn off "Start tracing" is if there are no > tracepoints defined in the workspace. > > If you find it is something a user would expect, then we can do that. Can we > make that a new bug? > I forgot about it. In this case my suggestion would make things more confusing. Let keep it as it is now and wait for feedback from real users.
