* Gdb gets confused @ 1996-06-21 0:00 Michael Rowley 1996-06-22 0:00 ` Robert Dewar 1996-06-22 0:00 ` Gdb gets confused Robert Dewar 0 siblings, 2 replies; 5+ messages in thread From: Michael Rowley @ 1996-06-21 0:00 UTC (permalink / raw) I hope someone knows of a work-around to a nasty problem in GDB when using it with Gnat. We have been using the Ada aware version of GDB (version 4.15.1.gnat.1.10) which usually works great, except that sometimes when it hits a break it gets confused about what function it is in. It correctly identifies the line number and file of the break, but it thinks that it is in a different function from the same file. When it does this it is a pain. We can't see the local variables or arguments, and it can't even step correctly. We suspect it has something to do with the order of the function definitions in the spec and/or the body, and seems to be more common in packages with a lot of dispatching functions. Does anyone know how to get around this problem? Thanks in advance. Michael Rowley rowley@inment.com ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Gdb gets confused 1996-06-21 0:00 Gdb gets confused Michael Rowley @ 1996-06-22 0:00 ` Robert Dewar 1996-06-26 0:00 ` GNAT tracking #s Peter Hermann 1996-06-22 0:00 ` Gdb gets confused Robert Dewar 1 sibling, 1 reply; 5+ messages in thread From: Robert Dewar @ 1996-06-22 0:00 UTC (permalink / raw) "We have been using the Ada aware version of GDB (version 4.15.1.gnat.1.10) which usually works great, except that sometimes when it hits a break it gets confused about what function it is in. It correctly identifies the line number and file of the break, but it thinks that it is in a different function from the same file. When it does this it is a pain. We can't see the local variables or arguments, and it can't even step correctly." Incidentally, when you report this to report@gnat.com, you must send along an example, and the chances of the problem being looked at increase inversely with the size of the example you can find that shows the problem. Be sure to say what version of the system you are using. In general, the way we work at ACT is that for our supported customers, we deal with their big programs and real applications if necessary to track down problems (though even there of course it always helps if things can be narrowed down). For unsupported users of GNAT and related tools, we accept bug reports at report@gnat.com and eventually process them, but at low priority. In practice, such reports have a much better chance of being looked at some time soon if they are narrowed down to small examples. A vague report with no details (such as the one above), or a giant program with a note saying simply "this doesn't work, please fix it", is unlikely to get looked at any time soon! Robert Dewar ACT ^ permalink raw reply [flat|nested] 5+ messages in thread
* GNAT tracking #s 1996-06-22 0:00 ` Robert Dewar @ 1996-06-26 0:00 ` Peter Hermann 1996-06-28 0:00 ` Robert Dewar 0 siblings, 1 reply; 5+ messages in thread From: Peter Hermann @ 1996-06-26 0:00 UTC (permalink / raw) Robert Dewar (dewar@cs.nyu.edu) wrote: : For unsupported users of GNAT and related tools, we accept bug reports : at report@gnat.com and eventually process them, but at low priority. Robert, after transition from GNAT to ACT you seem to no longer assign tracking numbers to feedback-contributions of unsupported users of GNAT. (I intentionally omit the word "bug report"). Could you imagine the introduction of some "muddy tracking numbers"? ;-) ps.: Of course, I know, you DON'T read CLA :-) -- Peter Hermann Tel:+49-711-685-3611 Fax:3758 ph@csv.ica.uni-stuttgart.de Pfaffenwaldring 27, 70569 Stuttgart Uni Computeranwendungen Team Ada: "C'mon people let the world begin" (Paul McCartney) ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: GNAT tracking #s 1996-06-26 0:00 ` GNAT tracking #s Peter Hermann @ 1996-06-28 0:00 ` Robert Dewar 0 siblings, 0 replies; 5+ messages in thread From: Robert Dewar @ 1996-06-28 0:00 UTC (permalink / raw) Peter Herman wrote "Robert, after transition from GNAT to ACT you seem to no longer assign tracking numbers to feedback-contributions of unsupported users of GNAT. (I intentionally omit the word "bug report"). Could you imagine the introduction of some "muddy tracking numbers"? ;-)" First, you really mean transition from NYU to ACT, not GNAT to ACT, since we are talking about GNAT in either case. At NYU, we were being funded by the US DoD to develop GNAT and provide general support for GNAT. That funding ended in July of 1995, at which time ACT took on the support. We no longer have specific funding for providing support for the general user community. As I have noted before we do accept bug reports from anyone and eventually look at them, but we minimize the effort that is required for processing these reports, and in particular, we do not assign tracking numbers to those who submit them, or enter into discussions about their status [except in specific cases where it seems useful to us to do so]. Sure I realize you would prefer that we do the extra work to assign these tracking numbers (and indeed that we provide free support for everyone :-) However, I am afraid the US government funded free lunch is over here. We certainly appreciate the fact that the DoD was willing to launch this project, but we also agree that it is perfectly reasonable for them not to fund it in this general manner indefinitely, and that it makes better sense all round for those who need GNAT support to be the ones who pay for it. We will do our best to maintain general availability of lastest versions of GNAT, both in binary and source form (note that that there is nothing in the GPL, or in the way GNAT is set up that requires us to make these versions available, it is something we choose to do as part of our effort to encourage widespread use of Ada). We will also continue to accept bug reports from everyone, and eventually to fix all the bugs that are reported, but that's the extent of the free support that is available at the current time from Ada Core Technologies. Robert Dewar Ada Core Technologies ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Gdb gets confused 1996-06-21 0:00 Gdb gets confused Michael Rowley 1996-06-22 0:00 ` Robert Dewar @ 1996-06-22 0:00 ` Robert Dewar 1 sibling, 0 replies; 5+ messages in thread From: Robert Dewar @ 1996-06-22 0:00 UTC (permalink / raw) Michael said "We have been using the Ada aware version of GDB (version 4.15.1.gnat.1.10) which usually works great, except that sometimes when it hits a break it gets confused about what function it is in. It correctly identifies the line number and file of the break, but it thinks that it is in a different function from the same file. When it does this it is a pain. We can't see the local variables or arguments, and it can't even step correctly." What optimization level are you using? Code merging and inlining in higher optimization levels can sometimes cause this. Some standard debugging formats are simply not expressive enough to represent the effects of such optimizations. If you are seeing this in -O0 mode, it certainly represents a bug. I assume you have reported this to report@gnat.com? The folks at ACT who know about GDB don't read CLA! ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~1996-06-28 0:00 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1996-06-21 0:00 Gdb gets confused Michael Rowley 1996-06-22 0:00 ` Robert Dewar 1996-06-26 0:00 ` GNAT tracking #s Peter Hermann 1996-06-28 0:00 ` Robert Dewar 1996-06-22 0:00 ` Gdb gets confused Robert Dewar
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox