Bug 473208 - Add new breakpoint action type to run a GDB script
Summary: Add new breakpoint action type to run a GDB script
Status: NEW
Alias: None
Product: CDT
Classification: Tools
Component: cdt-debug-dsf-gdb (show other bugs)
Version: 8.8.0   Edit
Hardware: All All
: P3 enhancement (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact: Jonah Graham CLA
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-07-21 10:54 EDT by Nobody - feel free to take it CLA
Modified: 2020-09-04 15:17 EDT (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nobody - feel free to take it CLA 2015-07-21 10:54:05 EDT
Add a new breakpoint action type that runs a GDB script when the breakpoint is hit.
Comment 1 Eclipse Genie CLA 2015-07-24 14:53:59 EDT
New Gerrit change created: https://git.eclipse.org/r/52520
Comment 2 Nobody - feel free to take it CLA 2015-07-24 15:12:38 EDT
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.
Comment 3 Marc Khouzam CLA 2015-07-24 15:28:18 EDT
(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
Comment 4 Nobody - feel free to take it CLA 2015-07-24 16:18:33 EDT
(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.
Comment 5 Eclipse Genie CLA 2015-07-27 09:42:43 EDT
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
Comment 6 Marc Khouzam CLA 2015-07-28 10:35:17 EDT
(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.
Comment 7 Marc Khouzam CLA 2015-07-28 10:46:01 EDT
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?
Comment 8 Nobody - feel free to take it CLA 2015-07-28 10:50:52 EDT
(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.
Comment 9 Nobody - feel free to take it CLA 2015-07-28 11:00:46 EDT
(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?
Comment 10 Marc Khouzam CLA 2015-07-28 11:38:05 EDT
(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.
Comment 11 Marc Khouzam CLA 2015-07-28 15:33:29 EDT
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?
Comment 12 Nobody - feel free to take it CLA 2015-07-28 20:57:31 EDT
(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?
Comment 13 Marc Khouzam CLA 2015-07-28 21:59:57 EDT
(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.
Comment 14 Nobody - feel free to take it CLA 2015-07-29 13:07:28 EDT
(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?
Comment 15 Marc Khouzam CLA 2015-07-29 13:20:17 EDT
(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)?
Comment 16 Nobody - feel free to take it CLA 2015-07-29 13:50:15 EDT
(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.
Comment 17 Marc Khouzam CLA 2015-07-29 16:46:29 EDT
(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!
Comment 18 Nobody - feel free to take it CLA 2015-07-29 17:51:53 EDT
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.
Comment 19 Marc Khouzam CLA 2015-07-30 09:35:05 EDT
(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?
Comment 20 Marc Khouzam CLA 2015-07-30 10:02:03 EDT
(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.
Comment 21 Marc Khouzam CLA 2015-07-30 11:01:00 EDT
I've opened the following bug on GDB about the messed up MI output:
https://sourceware.org/bugzilla/show_bug.cgi?id=18742
Comment 22 Nobody - feel free to take it CLA 2015-07-30 11:15:18 EDT
(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 :)
Comment 23 Nobody - feel free to take it CLA 2015-07-30 11:20:33 EDT
(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?
Comment 24 Marc Khouzam CLA 2015-07-30 11:33:28 EDT
(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\""
Comment 25 Marc Khouzam CLA 2015-07-30 11:47:54 EDT
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?
Comment 26 Marc Khouzam CLA 2015-07-30 11:50:44 EDT
(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)?
Comment 27 Nobody - feel free to take it CLA 2015-07-30 12:04:26 EDT
(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.
Comment 28 Nobody - feel free to take it CLA 2015-07-30 12:20:56 EDT
(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?
Comment 29 Marc Khouzam CLA 2015-07-30 16:01:35 EDT
(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?
Comment 30 Nobody - feel free to take it CLA 2015-07-31 12:31:16 EDT
(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.
Comment 31 Marc Khouzam CLA 2015-07-31 12:52:51 EDT
(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.
Comment 32 Eclipse Genie CLA 2016-03-11 11:06:55 EST
New Gerrit change created: https://git.eclipse.org/r/68214