Debugger for GNAT
in [ADA]
|
Next: tasksing and TCP sockets
From: markp on 18 Nov 2005 07:43 We are currently using the GPS debugger for our GNAT Ada applications. We feel it is not a very robust debugger, although that could be our limited experience with it. For example, we would to be able to break on any exceptions and view the offending line in the debugger and trace to the source. Also, we would like to be able to set breakpoints in tasks while the program is running without stopping everything, i.e. stopping a single task. Are there any other debuggers out the to debug our GNAT Ada? Thank you.
From: Jeff Creem on 18 Nov 2005 09:07 markp wrote: > We are currently using the GPS debugger for our GNAT Ada applications. > We feel it is not a very robust debugger, although that could be our > limited experience with it. For example, we would to be able to break > on any exceptions and view the offending line in the debugger and trace > to the source. Also, we would like to be able to set breakpoints in This should work. enter break exception in the command window. Perhaps I am not understanding the question/concern because this is pretty clear in the GNAT/gdb documentation. > tasks while the program is running without stopping everything, i.e. > stopping a single task. Not sure about this one. All GNAT debuggers I know of are based on gdb so I think the question (in terms that make sense to gdb people) to look into is it possible to set a breakpoint in a single thread under gdb such that when one thread stops at a breakpoint, other threads still continue. The answer may end up depending on the OS.. > > Are there any other debuggers out the to debug our GNAT Ada? > > Thank you. > I have used ddd quite a bit. Most gdb GUI front ends will work. Sometimes to use them with Ada you have to get used to a few quirks or worse yet read the documentation :)
From: Marc A. Criley on 18 Nov 2005 09:11 markp wrote: > We are currently using the GPS debugger for our GNAT Ada applications. > We feel it is not a very robust debugger, although that could be our > limited experience with it. For example, we would to be able to break > on any exceptions and view the offending line in the debugger and trace > to the source. Also, we would like to be able to set breakpoints in > tasks while the program is running without stopping everything, i.e. > stopping a single task. > > Are there any other debuggers out the to debug our GNAT Ada? GPS is built around gdb, and while I still use the old gvd interface for 3.15p, I know you can certainly set a breakpoint on any or all user-defined and predefined exceptions and trace them back to the source. At the very least set a breakpoint on all exceptions (the gdb command is "b except" and when it breaks, go up the call stack to get back to the offending line of your code. I'm hard pressed to see how one could break on a task and provide an interactive interface to the user, while allowing the rest of the program to continue running. I'm not saying it can't be done, but it sure looks tricky. I think it would behoove y'all to increase your limited experience with the debugger :-) Ask how to do things here, or over on the GPS mailing list, and you should find advice and suggestions readily available. -- Marc A. Criley -- McKae Technologies -- www.mckae.com -- DTraq - XPath In Ada - XML EZ Out
From: Simon Wright on 18 Nov 2005 17:47 "markp" <markwork66(a)yahoo.com> writes: > We are currently using the GPS debugger for our GNAT Ada applications. > We feel it is not a very robust debugger, although that could be our > limited experience with it. For example, we would to be able to break > on any exceptions and view the offending line in the debugger and trace > to the source. Also, we would like to be able to set breakpoints in > tasks while the program is running without stopping everything, i.e. > stopping a single task. I don't see how your problem with breaking on exceptions can be said to make the debugger not _robust_. To set breakpoints on all exceptions via menus, try Debug / Initialize / your_program, then Debug / Data / Edit breakpoints and go to the Exception tab, then immediately click on the Add button at top right -- this selects all exceptions. If I remember correctly you could also type eg Constraint_Error where it starts off saying 'All exceptions'. Under VxWorks the recommended method of debugging indeed stops just the current task while the rest of the system trundles on. Not always the most convenient thing to happen, and you can't just skip over to another task to see what it's up to. I believe that most conventional OSs stop the whole program.
From: Anonymous Coward on 19 Nov 2005 10:39
Regarding this discussion as to whether GDB is robust, I've encountered many problems with GDB, many of which I believe are not user errors. I'd like to post some examples of the anomalies I've observed, to see if you folks can discover user errors that I'm unaware of. Here is the first example. Keeping it simple, I'm merely asking gdb to list the functions that I can set breakpoints in. [hello_world.adb] with Ada.Text_IO; procedure Hello_World is function Hello_World_String return String is begin return "Hello world!"; end Hello_World_String; begin Ada.Text_IO.Put_Line(Hello_World_String); end Hello_World; compiled as: $ gnatmake -O0 -ggdb hello_world.adb gcc -c -O0 -ggdb hello_world.adb gnatbind -x hello_world.ali gnatlink -ggdb hello_world.ali GDB session: GNU gdb Red Hat Linux (5.3post-0.20021129.18rh) (gdb) file hello_world Reading symbols from hello_world...done. (gdb) info function internal error - unimplemented function unk_lang_create_fundamental_type called. (gdb) break hello_world.adb:14 internal error - unimplemented function unk_lang_create_fundamental_type called. So GDB finds no functions, and it also fails to set a breakpoint on line 14. |