Community
Participate
Working Groups
Add a new breakpoint action type that runs a GDB script when the breakpoint is hit.
New Gerrit change created: https://git.eclipse.org/r/52520
Marc, I pushed a patch to Gerrit: https://git.eclipse.org/r/#/c/52520/. Can you please take a look? I just followed the implementation for other breakpoint actions even though I don't like how it is done. I didn't make changes in the schema definition, it should be a separate patch. The patch includes the change in MIBreakpointManager that allows providing an adapter different than BreakpoinActionAdapter. The patch also includes tests for GDB scripts. I can't run tests for all GDB versions but tried the basic one and it seems to be fine. BTW, I wrote a small utility that generates tests for all GDB versions from a base test class and updates the test suites. Do we have something like that? If not, would you be interested in adding it to CDT.
(In reply to Mikhail Khodjaiants from comment #2) > Marc, > > I pushed a patch to Gerrit: https://git.eclipse.org/r/#/c/52520/. Can you > please take a look? Thanks! Will do. > I just followed the implementation for other breakpoint actions even though > I don't like how it is done. I didn't make changes in the schema definition, > it should be a separate patch. Agreed. > The patch includes the change in MIBreakpointManager that allows providing > an adapter different than BreakpoinActionAdapter. > The patch also includes tests for GDB scripts. I can't run tests for all GDB > versions but tried the basic one and it seems to be fine. I can try to run the older version tests. > BTW, I wrote a small utility that generates tests for all GDB versions from > a base test class and updates the test suites. Do we have something like > that? If not, would you be interested in adding it to CDT. Sounds great! You could add it to org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.tests.dsf.gdb/scripts
(In reply to Marc Khouzam from comment #3) > Sounds great! > You could add it to > org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.tests.dsf.gdb/scripts It's a Java program, do you think "scripts" is the right place for it? In theory it can be transformed it into a plugin that would allow users to select a test class from "tests" in the navigator and generate tests for it for all test suites.
WARNING: this patchset contains 1008 new lines of code and may require a Contribution Questionnaire (CQ) if the author is not a committer on the project. Please see:https://wiki.eclipse.org/Project_Management_Infrastructure/Creating_A_Contribution_Questionnaire
(In reply to Mikhail Khodjaiants from comment #4) > (In reply to Marc Khouzam from comment #3) > > Sounds great! > > You could add it to > > org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.tests.dsf.gdb/scripts > > It's a Java program, do you think "scripts" is the right place for it? > In theory it can be transformed it into a plugin that would allow users to > select a test class from "tests" in the navigator and generate tests for it > for all test suites. Then I don't really know where it belongs. Do we have a plugin for internal tools, views, etc? What is o.e.cdt.util for? Do you know? There is only one class it in and it does not look like it is used anywhere.
I was thinking about this and I wondered if it would be a user-friendly enhancement to allow the user to type the script directly into a text box in the GDB Script action dialogue? We could store those commands into a file ourselves and then everything else should stay the same. Do you think it would be a nice option for the user?
(In reply to Marc Khouzam from comment #6) > (In reply to Mikhail Khodjaiants from comment #4) > > (In reply to Marc Khouzam from comment #3) > > > Sounds great! > > > You could add it to > > > org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.tests.dsf.gdb/scripts > > > > It's a Java program, do you think "scripts" is the right place for it? > > In theory it can be transformed it into a plugin that would allow users to > > select a test class from "tests" in the navigator and generate tests for it > > for all test suites. > > Then I don't really know where it belongs. Do we have a plugin for internal > tools, views, etc? What is o.e.cdt.util for? Do you know? There is only one > class it in and it does not look like it is used anywhere. The problem with the plugin is that it has to work with the current workspace, so it has to be installed separately from CDT. Anyway, it's a long shot, if I have time to clean it up, I'll just leave it as a Java program maybe with a launcher associated with it.
(In reply to Marc Khouzam from comment #7) > I was thinking about this and I wondered if it would be a user-friendly > enhancement to allow the user to type the script directly into a text box in > the GDB Script action dialogue? We could store those commands into a file > ourselves and then everything else should stay the same. > > Do you think it would be a nice option for the user? I thought about it, it would be a nice option. I just decided to go with the simple case, at least for now. Do you think we should do it now?
(In reply to Mikhail Khodjaiants from comment #9) > (In reply to Marc Khouzam from comment #7) > > I was thinking about this and I wondered if it would be a user-friendly > > enhancement to allow the user to type the script directly into a text box in > > the GDB Script action dialogue? We could store those commands into a file > > ourselves and then everything else should stay the same. > > > > Do you think it would be a nice option for the user? > > I thought about it, it would be a nice option. I just decided to go with the > simple case, at least for now. Do you think we should do it now? It is your contribution, so we'll take what you are willing to give :) So if the script file is what your users need, that is fine. If you feel you want to add the text box because it will be good for your users, then good stuff for CDT. Either way, the patch can go in without the enhancement and the enhancement can be added after, if you, or anyone else wants to work on it.
I've been discussing this feature with our GDB guys. We all want to be able to run GDB commands when a breakpoint is hit :) They were wondering why we would take the approach to have Eclipse send the 'source <script>' command when the bp is hit, instead of attaching the script commands to the breakpoint in GDB itself? I realize that CDT's other bp actions are Eclipse actions and should be handled by Eclipse, but the GDB script/commands could be handled by GDB as GDB bp commands. It would be more efficient as the commands would run in GDB directly, without needing Eclipse to send those commands where the bp is hit. CDT Tracepoints actions all work like that (there is no other way in that case). We could do something similar and use -break-commands when the bp is created or modified, to tell GDB what to do when a breakpoint will eventually hit, instead of having Eclipse do it. What do you think?
(In reply to Marc Khouzam from comment #11) > I've been discussing this feature with our GDB guys. We all want to be able > to run GDB commands when a breakpoint is hit :) > > They were wondering why we would take the approach to have Eclipse send the > 'source <script>' command when the bp is hit, instead of attaching the > script commands to the breakpoint in GDB itself? > > I realize that CDT's other bp actions are Eclipse actions and should be > handled by Eclipse, but the GDB script/commands could be handled by GDB as > GDB bp commands. It would be more efficient as the commands would run in > GDB directly, without needing Eclipse to send those commands where the bp is > hit. > > CDT Tracepoints actions all work like that (there is no other way in that > case). We could do something similar and use -break-commands when the bp is > created or modified, to tell GDB what to do when a breakpoint will > eventually hit, instead of having Eclipse do it. > > What do you think? I'll take a look at the tracepoint implementation. In case of a script file should we read it and translate into a list of commands or still use the 'source' command as a breakpoint command?
(In reply to Mikhail Khodjaiants from comment #12) > I'll take a look at the tracepoint implementation. In case of a script file > should we read it and translate into a list of commands or still use the > 'source' command as a breakpoint command? I think we may get some validation from GDB if we send a list of commands. Our GDB guys here also prefer the list of commands if it's not too complicated.
(In reply to Marc Khouzam from comment #11) > I've been discussing this feature with our GDB guys. We all want to be able > to run GDB commands when a breakpoint is hit :) > > They were wondering why we would take the approach to have Eclipse send the > 'source <script>' command when the bp is hit, instead of attaching the > script commands to the breakpoint in GDB itself? > > I realize that CDT's other bp actions are Eclipse actions and should be > handled by Eclipse, but the GDB script/commands could be handled by GDB as > GDB bp commands. It would be more efficient as the commands would run in > GDB directly, without needing Eclipse to send those commands where the bp is > hit. > > CDT Tracepoints actions all work like that (there is no other way in that > case). We could do something similar and use -break-commands when the bp is > created or modified, to tell GDB what to do when a breakpoint will > eventually hit, instead of having Eclipse do it. > > What do you think? There is no doubt that attaching the script commands to the breakpoint is the right thing to do. Unfortunately, there is a problem with the current breakpoint action framework: it allows attaching multiple actions to a breakpoint and specify the order of their execution. If we use breakpoint commands for scripts we can not mix it with Eclipse actions. The only solution I can think of is to forget the breakpoint actions and modify the "Common" page of the breakpoint properties by adding the script UI there. Would it be better?
(In reply to Mikhail Khodjaiants from comment #14) > There is no doubt that attaching the script commands to the breakpoint is > the right thing to do. Unfortunately, there is a problem with the current > breakpoint action framework: it allows attaching multiple actions to a > breakpoint and specify the order of their execution. If we use breakpoint > commands for scripts we can not mix it with Eclipse actions. I guess we could mix them, but the GDB Script command would always be run first by GDB. I don't think users will necessarily want to use both at once, but I agree that we need to address this anyway. Can we force GDB Script actions to always be at the top of the list, and put some text in the creating dialog explaining the difference? > The only solution I can think of is to forget the breakpoint actions and > modify the "Common" page of the breakpoint properties by adding the script > UI there. Would it be better? That would clearly show that GDB script actions are different, but it may look like a design mistake to users. Can we first see if we can tweak the GDB Script action to play nicely with other actions (discussion above)?
(In reply to Marc Khouzam from comment #15) > (In reply to Mikhail Khodjaiants from comment #14) > > > There is no doubt that attaching the script commands to the breakpoint is > > the right thing to do. Unfortunately, there is a problem with the current > > breakpoint action framework: it allows attaching multiple actions to a > > breakpoint and specify the order of their execution. If we use breakpoint > > commands for scripts we can not mix it with Eclipse actions. > > I guess we could mix them, but the GDB Script command would always be run > first by GDB. I don't think users will necessarily want to use both at > once, but I agree that we need to address this anyway. Can we force GDB > Script actions to always be at the top of the list, and put some text in the > creating dialog explaining the difference? > It may not be as simple as it looks. How do we find out when the running of the script commands is completed? We may get multiple "stopped" events, for instance and the actions will get mixed up. IMO, associating the script commands with the common properties is a better solution than mixing it with the breakpoint actions. It will show the special treatment of the script commands.
(In reply to Mikhail Khodjaiants from comment #16) > It may not be as simple as it looks. How do we find out when the running of > the script commands is completed? We may get multiple "stopped" events, for > instance and the actions will get mixed up. I'm not sure how we could get multiple events. Also, I wonder when GDB sends the stopped event, is it after the actions are done or before. If it's before then yes, we have a race. But we don't need to continue this route as it seems unsafe. > IMO, associating the script commands with the common properties is a better > solution than mixing it with the breakpoint actions. It will show the > special treatment of the script commands. I now see that you're right, that seems better. Thanks!
It seems that not all commands are working properly when using breakpoint commands. For instance, the following script works fine when I use "source": next info break source /home/mikhail/Shared-vm/csl-patches/CB4886/gdb_script.txt &"source /home/mikhail/Shared-vm/csl-patches/CB4886/gdb_script.txt\n" ^running *running,thread-id="all" (gdb) ~"14\t n = factorial (i);\n" *stopped,reason="end-stepping-range",frame={addr="0x0804841e",func="main",args=[],file="../src/factorial.c",fullname="/home/mikhail/cdt-runtime-workspaces/eclipse4.4-cdt8.4/factorial/src/factorial.c",line="14"},thread-id="1",stopped-threads="all",core="0" ~"Num Type Disp Enb Address What\n" ~"1 breakpoint keep y 0x08048414 in main at ../src/factorial.c:13\n" ~"\tbreakpoint already hit 1 time\n" ~" print i\n" (gdb) When I use -break-commands with the above commands, the output for "info break" doesn't appear after the step: -break-commands 2 "next" "info break" ^done (gdb) c &"c\n" ~"Continuing.\n" ^running *running,thread-id="all" (gdb) =breakpoint-modified,bkpt={number="2",type="breakpoint",disp="keep",enabled="y",addr="0x0804841e",func="main",file="../src/factorial.c",fullname="/home/mikhail/cdt-runtime-workspaces/eclipse4.4-cdt8.4/factorial/src/factorial.c",line="14",thread-groups=["i1"],times="1",script={"next","info break"},original-location="factorial.c:14"} ~"\nBreakpoint " ~"2, main () at ../src/factorial.c:14\n" ~"14\t n = factorial (i);\n" *stopped,reason="breakpoint-hit",disp="keep",bkptno="2",frame={addr="0x0804841e",func="main",args=[],file="../src/factorial.c",fullname="/home/mikhail/cdt-runtime-workspaces/eclipse4.4-cdt8.4/factorial/src/factorial.c",line="14"},thread-id="1",stopped-threads="all",core="0" *running,thread-id="all" *stopped,reason="end-stepping-range",frame={addr="0x0804842e",func="main",args=[],file="../src/factorial.c",fullname="/home/mikhail/cdt-runtime-workspaces/eclipse4.4-cdt8.4/factorial/src/factorial.c",line="15"},thread-id="1",stopped-threads="all",core="0" (gdb) I get the same result when I use "-break-commands 2 "source /home/mikhail/Shared-vm/csl-patches/CB4886/gdb_script.txt". It seems the commands after "next" are ignored in this case. I'm using GDB 7.9.
(In reply to Mikhail Khodjaiants from comment #18) > It seems the commands after "next" are ignored in this case. I'm using GDB > 7.9. I see that too. It sounded familiar so I looked around in the manual and found https://sourceware.org/gdb/onlinedocs/gdb/Break-Commands.html "Any other commands in the command list, after a command that resumes execution, are ignored. This is because any time you resume execution (even with a simple next or step), you may encounter another breakpoint—which could have its own command list, leading to ambiguities about which list to execute." That being said, when I try some info commands before or without any run control commands, I see some weird behaviour. For example, using -break-commands "info b" then I don't see the output when hitting the breakpoint. But when I manually type "info b" after, I see extra MI output showing a breakpoint table. And like you, I see the same weird output when using 'source script'. Sometimes the bp table output even replaces the proper output of the *stopped event! I've tried with 7.5, 7.8 and the upcoming 7.10 and I see this every time. So, it looks like GDB bp command output does not work well in MI mode. If we agree that the eventual better solution is to use GDB bp commands, what do you think of implementing the solution in CDT is such a way that we can have CDT issue the "source script" command itself (as you did at the start), but that we can change that without affecting the UI, if GDB fixes the issue?
(In reply to Marc Khouzam from comment #19) > That being said, when I try some info commands before or without any run > control commands, I see some weird behaviour. I've had a chat with one of our GDB guys and we both feel this is a bug in GDB; I'll open a bug on GDB. But we also think there is a workaround. The GDB bug is that GDB runs the bp commands in MI mode, instead of CLI mode; so, we could force it to run them in CLI mode by using "interpreter-exec console" for each bp command. For example, we can send -break-commands 1 "interpreter-exec console \"info b\"" which works for me. This workaround would continue working even when GDB fixes its bug, so it may be worth trying as a solution.
I've opened the following bug on GDB about the messed up MI output: https://sourceware.org/bugzilla/show_bug.cgi?id=18742
(In reply to Marc Khouzam from comment #19) > (In reply to Mikhail Khodjaiants from comment #18) > > > It seems the commands after "next" are ignored in this case. I'm using GDB > > 7.9. > > I see that too. It sounded familiar so I looked around in the manual and > found > https://sourceware.org/gdb/onlinedocs/gdb/Break-Commands.html > > "Any other commands in the command list, after a command that resumes > execution, are ignored. This is because any time you resume execution (even > with a simple next or step), you may encounter another breakpoint—which > could have its own command list, leading to ambiguities about which list to > execute." > > That being said, when I try some info commands before or without any run > control commands, I see some weird behaviour. For example, using > > -break-commands "info b" > > then I don't see the output when hitting the breakpoint. But when I > manually type "info b" after, I see extra MI output showing a breakpoint > table. And like you, I see the same weird output when using 'source script'. > > Sometimes the bp table output even replaces the proper output of the > *stopped event! > > I've tried with 7.5, 7.8 and the upcoming 7.10 and I see this every time. > > So, it looks like GDB bp command output does not work well in MI mode. > > If we agree that the eventual better solution is to use GDB bp commands, > what do you think of implementing the solution in CDT is such a way that we > can have CDT issue the "source script" command itself (as you did at the > start), but that we can change that without affecting the UI, if GDB fixes > the issue? That's what I was about to propose :)
(In reply to Marc Khouzam from comment #20) > (In reply to Marc Khouzam from comment #19) > > > That being said, when I try some info commands before or without any run > > control commands, I see some weird behaviour. > > I've had a chat with one of our GDB guys and we both feel this is a bug in > GDB; I'll open a bug on GDB. But we also think there is a workaround. The > GDB bug is that GDB runs the bp commands in MI mode, instead of CLI mode; > so, we could force it to run them in CLI mode by using "interpreter-exec > console" for each bp command. > > For example, we can send > > -break-commands 1 "interpreter-exec console \"info b\"" > > which works for me. > > This workaround would continue working even when GDB fixes its bug, so it > may be worth trying as a solution. I've seen the same behavior when using 'source <script_file>' as a breakpoint command with "info break" in the script file. The workaround is good for the new scripts. Re-using existing scripts would require modifying them, right?
(In reply to Mikhail Khodjaiants from comment #23) > I've seen the same behavior when using 'source <script_file>' as a > breakpoint command with "info break" in the script file. > The workaround is good for the new scripts. Re-using existing scripts would > require modifying them, right? I believe the workaround works on scripts by wrapping the source command itself: -break-commands 1 "interpreter-exec console \"source script\""
Sigh... There seems to be yet another weird behaviour in GDB, this time when using a script with run-control content from a bp command. So if my script is simply 'continue', then sourcing the script in a GDB bp command does not seem to work as expected, but instead buffers the 'continue' or something. Maybe we should not use 'source script' at all but, if we want to offer a script option to the user, convert each script line into an explicit GDB command?
(In reply to Mikhail Khodjaiants from comment #16) > IMO, associating the script commands with the common properties is a better > solution than mixing it with the breakpoint actions. It will show the > special treatment of the script commands. I just thought that the 'common' bp page is probably shared with Tracepoints and Dynamic-printf, so adding the GDB commands there may not be good. How about a new bp properties page called "GDB commands" (or something like that)?
(In reply to Marc Khouzam from comment #25) > Sigh... There seems to be yet another weird behaviour in GDB, this time when > using a script with run-control content from a bp command. So if my script > is simply 'continue', then sourcing the script in a GDB bp command does not > seem to work as expected, but instead buffers the 'continue' or something. > > Maybe we should not use 'source script' at all but, if we want to offer a > script option to the user, convert each script line into an explicit GDB > command? We may have problems with quoting. As far as I understand, the scripts could be quite complicated, I don't know how to convert them to the format expected by -break-commands.
(In reply to Marc Khouzam from comment #26) > (In reply to Mikhail Khodjaiants from comment #16) > > > IMO, associating the script commands with the common properties is a better > > solution than mixing it with the breakpoint actions. It will show the > > special treatment of the script commands. > > I just thought that the 'common' bp page is probably shared with Tracepoints > and Dynamic-printf, so adding the GDB commands there may not be good. How > about a new bp properties page called "GDB commands" (or something like > that)? In theory this page would be shared by all debugger types, so having "GDB" in the name is not good. At the same time explaining the differences between "Commands" and "Actions" would be difficult :( It seems the original approach to use the "Actions" page is the lesser of all evils. Sorry for diverting the discussion in wrong direction. Basically we can keep the original patch and modify it when GDB is fixed. What do you think?
(In reply to Mikhail Khodjaiants from comment #28) > It seems the original approach to use the "Actions" page is the lesser of > all evils. Sorry for diverting the discussion in wrong direction. Basically > we can keep the original patch and modify it when GDB is fixed. What do you > think? Do you mean to use GDB commands but from the Actions page? That is ok with me. Do you think we should make sure they are always at the top of the actions list?
(In reply to Marc Khouzam from comment #29) > (In reply to Mikhail Khodjaiants from comment #28) > > > It seems the original approach to use the "Actions" page is the lesser of > > all evils. Sorry for diverting the discussion in wrong direction. Basically > > we can keep the original patch and modify it when GDB is fixed. What do you > > think? > > Do you mean to use GDB commands but from the Actions page? That is ok with > me. Do you think we should make sure they are always at the top of the > actions list? It's not easy to do it without modifying the breakpoint action framework. All actions are contributed and the framework is not aware of any of them, so it has to be extended to allow actions to somehow control the order of their appearance in the list. The other option is to add a warning to the script action page and leave it to the user.
(In reply to Mikhail Khodjaiants from comment #30) > It's not easy to do it without modifying the breakpoint action framework. > All actions are contributed and the framework is not aware of any of them, > so it has to be extended to allow actions to somehow control the order of > their appearance in the list. > The other option is to add a warning to the script action page and leave it > to the user. Let's see how things feel and we can decide how bad/good the user-experience is before choosing a solution for that particular point.
New Gerrit change created: https://git.eclipse.org/r/68214