Re: New Ada failure

[Joel Brobecker <brobecker at adacore dot com>]

> (gdb) catch exception
> Cannot break on __gnat_raise_nodefer_with_msg in this configuration.
> 
> The symbol is present, in my shared libgnat.so.  I have a stripped
> libgnat, unsurprisingly.  I think the problem is that you're using
> lookup_symbol; isn't lookup_minimal_symbol sufficient?

I added a big comment in the code to explain why I use the debugging
info and not the symbol table:

  /* The symbol we're looking up is provided by a unit in the GNAT runtime
     that should be compiled with debugging information.  As a result, we
     expect to find that symbol in the symtabs.  If we don't find it, then
     the target most likely does not support Ada exceptions, or we cannot
     insert exception breakpoints yet, because the GNAT runtime hasn't been
     loaded yet.  */

  /* brobecker/2006-12-26: It is conceivable that the runtime was compiled
     in such a way that no debugging information is produced for the symbol
     we are looking for.  In this case, we could search the minimal symbols
     as a fall-back mechanism.  This would still be operating in degraded
     mode, however, as we would still be missing the debugging information
     that is needed in order to extract the name of the exception being
     raised (this name is printed in the catchpoint message, and is also
     used when trying to catch a specific exception).  We do not handle
     this case for now.  */

As Robert explained, once we hit the breakpoint, we need to evaluate
certain expressions: Either id.full_name, or e.full_name (depending
on the situation). "e" is a function parameter, but id is a local
variable.

I am open to adding a lookup in the minimal symbol table if you like.
That's going to introduce a bit of complication, however, because we
then have to reject the case where the user asks to break on a specific
exception.  We already have some code that handles evaluation failures
when trying to read the name of the exception, so we don't need to take
care of that part.

I am not sure why you stripped your libgnat.so. From your other messages,
it sounds like something that you must do. At least with GNAT Pro,
the runtime is built at -O2 and without -g, except for a few select units
which are deliberately built with -g (and often -O1 instead of -O2).
To us, if you strip the runtime, then you break the compiler-debugger
interface.

Would you consider not stripping libgnat.so?

-- 
Joel