OMEdit gdb debugging - desired features

[Adrian Pop]

I would really like to extend the GDB debugger features in
OMEdit compared to MDT. I've been playing a lot with the MDT
debugging and while is quite good, it can be way better which
would support way more effective debugging.

Per and Martin, add more to this list if you want.

Adeel, I can make it a ticket out of this if you want -> done :)

1. have a user console to send written commands to gdb (for advanced users like Martin and me). You can use -interpreter-exec console "command" ​http://www.sourceware.org/gdb/onlinedocs/gdb.html#g_t_002dinterpreter_002dexec

2. have an user option in OMEdit debugging settings to not remove frames that are for .c/.cpp files. Note that some of these files are quite large (100Mb+) and should not be fully opened in OMEdit just display 100 lines above and below the breakpoint line.

3. when your program cycles and you suspend it sometimes it switches threads so you get a different stack that you want. have a way to switch the threads or display all threads instead of just the one executing .mo code.

4. have a way to search the (tree-like) local variables for strings, record names, record component names if possible with regular expressions.

5. have a way to break only if a local variable contains certain record name or string. sometimes a function is executed a lot of times but you're only interested if the input/local variable path (Absyn.Path) contains certain string. currently you have to suffer through stopping *a lot* of times until you reach the point you're interested in.

6. have a toggle button that enables timings for step in, step over run commands. if you send command: -enable-timings [yes | no] then when you do step over or run gdb measures time until the next break event and report it then in this way: time={wallclock="0.05185",user="0.00800",system="0.00000"}. the execution time until the next breakpoint is hit can then be displayed somewhere.

[Adeel Asghar]

I have merged the debugger with the trunk and few of the features listed are done now.

1. Users can send custom commands.
2. There is an option to enable/disable C frames but the debugger will not stop at the C frames. However, the C frames will be displayed in the stack.
3. There is drop-down to select threads.

[Martin Sjölund]

The following needs to be taken care of:

1. It is not possible to start the process paused (to add breakpoints easily)
2. It is not possible to browse the functions of the executable to choose one of them to add a breakpoint at
3. When browsing for a class (function/record) to break at, the debugger creates a breakpoint at line 0 in the file. Instead of simply adding a breakpoint at the function (for example, add a breakpoint for class Modelica.Mechanics.MultiBody.Frames.TransformationMatrices.from_nxy should break at omc_Modelica_Mechanics_MultiBody_Frames_TransformationMatrices_from__nxy)
4. C frames are not shown, even when stopping in a C frame (like an external function causing a segmentation fault)
5. Launching the debugger does not seem to run with the same command-line arguments as when simulating normally
6. Clicking the pause button does not suspend the executable

[Adeel Asghar]

Replying to sjoelund.se:

The following needs to be taken care of:

1. It is not possible to start the process paused (to add breakpoints easily)

What do you mean?

2. It is not possible to browse the functions of the executable to choose one of them to add a breakpoint at
3. When browsing for a class (function/record) to break at, the debugger creates a breakpoint at line 0 in the file. Instead of simply adding a breakpoint at the function (for example, add a breakpoint for class Modelica.Mechanics.MultiBody.Frames.TransformationMatrices.from_nxy should break at omc_Modelica_Mechanics_MultiBody_Frames_TransformationMatrices_from__nxy)

Is this one comment with two different numbers? BTW, function breakpoints are not supported. If you browse a class you must specify a line number.

4. C frames are not shown, even when stopping in a C frame (like an external function causing a segmentation fault)

There are options in OptionsDialog to display C frames. Now I have the set these options to true by default.

5. Launching the debugger does not seem to run with the same command-line arguments as when simulating normally

What is the difference? I have to check it.

6. Clicking the pause button does not suspend the executable

Pause is not supported yet.

[Martin Sjölund]

Replying to adeas31:

1. It is not possible to start the process paused (to add breakpoints easily)

What do you mean?

If you start a simulation and choose to open the debugger, it runs the simulation without stopping. This means you have to set breakpoints, then re-compile, and run...

Is this one comment with two different numbers? BTW, function breakpoints are not supported. If you browse a class you must specify a line number.

Which is stupid and pointless. Of course we want to be able to break at a specific function. Should I really need to open a file editor to try to find out the line that a function begins at? In gdb I always use function breakpoints because they are much simpler to use.

4. C frames are not shown, even when stopping in a C frame (like an external function causing a segmentation fault)

There are options in OptionsDialog to display C frames. Now I have the set these options to true by default.

Sure, they are shown then. But the variables inside them are not.

5. Launching the debugger does not seem to run with the same command-line arguments as when simulating normally

What is the difference? I have to check it.

I do not get any LOG_STATS output, etc. This means you are debugging a different execution than the one you intended to. (Some flags cause seg.faults)

6. Clicking the pause button does not suspend the executable

Pause is not supported yet.

:(

[Adeel Asghar]

Replying to sjoelund.se:

Replying to adeas31:

1. It is not possible to start the process paused (to add breakpoints easily)

What do you mean?

If you start a simulation and choose to open the debugger, it runs the simulation without stopping. This means you have to set breakpoints, then re-compile, and run...

If you start a simulation without checking "launch debugger" simulation option then it is a normal simulation without gdb so adding breakpoints is not possible. You could try to attach the debugger but it will be useless since there is no -g used for compilation. But if "launch debugger" is checked then the simulation is started with gdb and you can set breakpoints etc.

Is this one comment with two different numbers? BTW, function breakpoints are not supported. If you browse a class you must specify a line number.

Which is stupid and pointless. Of course we want to be able to break at a specific function. Should I really need to open a file editor to try to find out the line that a function begins at? In gdb I always use function breakpoints because they are much simpler to use.

The function names are not same. In Modelica a function name is xyz but in simulation runtime it is omc_xyz. Anyways, I am currently adding more features in breakpoints e.g conditional breakpoints etc. so I will think about function breakpoints also.

4. C frames are not shown, even when stopping in a C frame (like an external function causing a segmentation fault)

There are options in OptionsDialog to display C frames. Now I have the set these options to true by default.

Sure, they are shown then. But the variables inside them are not.

It is possible to show variables but I need a lot of time to support C in debugger.

5. Launching the debugger does not seem to run with the same command-line arguments as when simulating normally

What is the difference? I have to check it.

I do not get any LOG_STATS output, etc. This means you are debugging a different execution than the one you intended to. (Some flags cause seg.faults)

True. You need to manually specify the arguments OR always use the simulation dialog. I can add a checkbox in simulation dialog like "Create debugger confiuration". If it is checked then create a new debugger configuration with all the arguments so that we can reuse it.

6. Clicking the pause button does not suspend the executable

Pause is not supported yet.

:(

It will be available soon.

[Martin Sjölund]

Replying to adeas31:

If you start a simulation without checking "launch debugger" simulation option then it is a normal simulation without gdb so adding breakpoints is not possible. You could try to attach the debugger but it will be useless since there is no -g used for compilation. But if "launch debugger" is checked then the simulation is started with gdb and you can set breakpoints etc.

No, I can not. Because if I check "launch debugger", the simulation runs so fast I can't do anything before it finishes.

The function names are not same. In Modelica a function name is xyz but in simulation runtime it is omc_xyz. Anyways, I am currently adding more features in breakpoints e.g conditional breakpoints etc. so I will think about function breakpoints also.

Yes, but you can just transform the class name into its function name. Or use an API call to ask what the name would be.

True. You need to manually specify the arguments OR always use the simulation dialog. I can add a checkbox in simulation dialog like "Create debugger confiuration". If it is checked then create a new debugger configuration with all the arguments so that we can reuse it.

No. Using the simulation dialog I get no output.

[Martin Sjölund]

This ticket was not closed for 1.9.1, which has now been released. It was batch modified for milestone 1.9.2 (but maybe an empty milestone was more appropriate; feel free to change it).

[Martin Sjölund]

Milestone changed to 1.9.3 since 1.9.2 was released.

[Martin Sjölund]

Moved to new milestone 1.9.4

[Martin Sjölund]

Milestone pushed to 1.9.5

[Martin Sjölund]

Milestone renamed

[Martin Sjölund]

Ticket retargeted after milestone closed

[Adeel Asghar]

Milestone changed to 1.12.0 since 1.11.0 was released.