Gdb gets confused

Gdb gets confused

[Michael Rowley]

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

Re: Gdb gets confused

[Robert Dewar]

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!

Re: Gdb gets confused

[Robert Dewar]

"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

GNAT tracking #s

[Peter Hermann]

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)

Re: GNAT tracking #s

[Robert Dewar]

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