Re: Quick Question about GPS IDE

[Brad Moore <brad.moore@shaw.ca>]

On 14-12-29 02:06 PM, ake.ragnar.dahlgren@gmail.com wrote:
> Dear all,
>
> I've also had problems with GDB as Dimitry describes. It seems to work for my small hobby projects at home, but for the applications at work it doesn't work as expected for me. When I set breakpoints, GDB may or may not stop execution upon them. If it has to do with a large code base or multi-threading, I've no idea. Anyways, if I ever run into GDB issue in an open source Ada project I will reopen this issue for discussion. Maybe somebody here could then point out where the problem lies.
>
> I am also thankful for the feedback that some Ada developers successfully use GDB in their projects.
>
> Best regards,
> Åke Ragnar Dahlgren
>

Some possibilities to explain why one cant set a breakpoint is that you 
need to ensure that the code you want to debug was been compiled with 
the debug flag turned on.  Look for -g on the command line.

If you are linking with third party libraries, or dynamically linked 
libraries, you need to ensure that those libraries have also been 
compiled with debug enabled, if you want to step into those library 
calls with the debugger.

If in GPS, you try to set a breakpoint and do not get visual feedback 
that the breakpoint was set, then it is a good idea to check the 
compilation flags. As I mentioned above, you should see a -g on the 
command  line for the compilation, in GNAT and gcc.

Another cause might be due to optimization, the code you want to set a 
breakpoint on, may have been optimized out. So usually when debugging, I 
tend to disable optimization flags.

Another possibility is that the code may not have been compiled since 
last edited, causing a discrepency between where the debugger thinks the 
source lines are, and where the editor shows them. Be sure to compile 
the latest version of the sources you want to debug.

Another trick I've learned is that stepping into a protected object 
doesnt usually work, probably because the thread that executes the 
protected action is not the same one that makes the call into the PO.

If you want to step into a PO, I find you usually need to set a 
breakpoint on the code inside the protected object. Then you can step 
through the code inside the protected object.

Sometimes GPS wont set a breakpoint on a particular line of source, 
usually because it does not represent executable code. (eg. A 
declaration of some variable that doesn't have any initialization).

For that case, try instead setting a breakpoint on a nearby line that is 
associated with a statement of execution.

Another point is that when setting breakpoints on function calls where 
the parameters span multiple source lines, you usually want to set a 
breakpoint on the last line of the call, if you want to catch the 
debugger just before stepping into the call. Otherwise, you might find 
that you need to step through execution associated with setting up each 
of the parameters.

Another usage I found very helpful is when a core-dump or stack trace is 
output, due to some exception being raised.

If the code was compiled with debug enabled, you can usually enter the 
address into gdb and see the code associated with the failure. The 
address reported I think is a return address, so quite often the line 
where you want to set a breakpoint, is the source line immediately 
before the line associated with the reported address. Usually it is 
obvious which line caused the problem.

If while stepping through the debugger, the code seems to be jumping 
wildly from one place to another, it is probably because multiple 
threads are executing, and each breakpoint in the debugger represents 
the progress of a different thread or task.

I find it handy to display the threads, and the backtrace windows in 
GPS. This shows which thread is associated with the current break in the 
debugger. Debugging multithreaded applications can be tricky. You may 
need to follow the thread you are interested in, and set lots of 
breakpoints around the area you are trying to debug.