From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!news.glorb.com!peer02.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!post02.iad.highwinds-media.com!fx30.iad.POSTED!not-for-mail From: Brad Moore User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Quick Question about GPS IDE References: <65Pnw.784261$_k.162865@fx16.iad> <1w1zdixq5j24a.4zrnyiwijmrj$.dlg@40tude.net> <1l3qw3vstmcag$.1qdkh60s0b38n$.dlg@40tude.net> <1hw9w1ecyf42u.1x8fovgepzisj.dlg@40tude.net> <1odwfl4m7imvn.r0p2gn37dn6p.dlg@40tude.net> <4lsidi60qdpo$.1nwjgjk69zaw7.dlg@40tude.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Message-ID: NNTP-Posting-Host: 68.145.219.148 X-Complaints-To: internet.abuse@sjrb.ca X-Trace: 1419897071 68.145.219.148 (Mon, 29 Dec 2014 23:51:11 UTC) NNTP-Posting-Date: Mon, 29 Dec 2014 23:51:11 UTC Date: Mon, 29 Dec 2014 16:51:12 -0700 X-Received-Bytes: 5412 X-Received-Body-CRC: 3365314445 Xref: news.eternal-september.org comp.lang.ada:24279 Date: 2014-12-29T16:51:12-07:00 List-Id: 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.