New Ada failure

New Ada failure

[Daniel Jacobowitz]

Breakpoint 1, main (argc=1, argv=140737488347304, envp=140737488347320) at b~foo.adb:99
99            Ensure_Reference : System.Address := Ada_Main_Program_Name'Address;
(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?

-- 
Daniel Jacobowitz
CodeSourcery

Re: New Ada failure

[Robert Dewar]

Daniel Jacobowitz wrote:
> Breakpoint 1, main (argc=1, argv=140737488347304, envp=140737488347320) at b~foo.adb:99
> 99            Ensure_Reference : System.Address := Ada_Main_Program_Name'Address;
> (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. 

Ada.Exceptions needs to be compiled with debug information and not
stripped, so if you strip, you will definitely disable this lookup

> I think the problem is that you're using
> lookup_symbol; isn't lookup_minimal_symbol sufficient?

Wouldn't really help, since once we break on this routine,
we look at its arguments and local variables, so we really
need full debug information for this routine. At least
that's my understanding.
> 

Re: New Ada failure

[Daniel Jacobowitz]

On Thu, Jan 04, 2007 at 06:09:52PM -0500, Robert Dewar wrote:
> >I think the problem is that you're using
> >lookup_symbol; isn't lookup_minimal_symbol sufficient?
> 
> Wouldn't really help, since once we break on this routine,
> we look at its arguments and local variables, so we really
> need full debug information for this routine. At least
> that's my understanding.

I see.  In that case, I think the best thing to do would be to mark the
test as unsupported in this configuration and return (and maybe mention
this in the manual).

If we only need its arguments, then a minimal symbol is sufficient.  If
we need named local variables, though, we're stuck.

-- 
Daniel Jacobowitz
CodeSourcery

Re: New Ada failure

[Mark Kettenis]

> Date: Thu, 04 Jan 2007 18:09:52 -0500
> From: Robert Dewar <dewar@adacore.com>
> 
> Ada.Exceptions needs to be compiled with debug information and not
> stripped, so if you strip, you will definitely disable this lookup
> 
> > I think the problem is that you're using
> > lookup_symbol; isn't lookup_minimal_symbol sufficient?
> 
> Wouldn't really help, since once we break on this routine,
> we look at its arguments and local variables, so we really
> need full debug information for this routine. At least
> that's my understanding.

But wouldn't it be useful to be able to catch exceptions, or at least
know that an exception was raised, even if you can't look at its
details?

Mark

Re: New Ada failure

[Robert Dewar]

Mark Kettenis wrote:
>> Date: Thu, 04 Jan 2007 18:09:52 -0500
>> From: Robert Dewar <dewar@adacore.com>
>>
>> Ada.Exceptions needs to be compiled with debug information and not
>> stripped, so if you strip, you will definitely disable this lookup
>>
>>> I think the problem is that you're using
>>> lookup_symbol; isn't lookup_minimal_symbol sufficient?
>> Wouldn't really help, since once we break on this routine,
>> we look at its arguments and local variables, so we really
>> need full debug information for this routine. At least
>> that's my understanding.
> 
> But wouldn't it be useful to be able to catch exceptions, or at least
> know that an exception was raised, even if you can't look at its
> details?

Sure, but you can do so fine if you build the library correctly,
which means not removing debugging information for this unit!
Not clear it is worth extra work to deal with misconfigured libraries.
> 
> Mark

Re: New Ada failure

[Daniel Jacobowitz]

On Thu, Jan 04, 2007 at 06:26:38PM -0500, Robert Dewar wrote:
> Sure, but you can do so fine if you build the library correctly,
> which means not removing debugging information for this unit!
> Not clear it is worth extra work to deal with misconfigured libraries.

When you come up with a magic incantation to strip debugging
information from a shared library except for one unit, please,
do let us know :-)

-- 
Daniel Jacobowitz
CodeSourcery

Re: New Ada failure

[Joel Brobecker]

> (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

Re: New Ada failure

[Daniel Jacobowitz]

On Fri, Jan 05, 2007 at 07:56:48AM +0400, Joel Brobecker wrote:
> I added a big comment in the code to explain why I use the debugging
> info and not the symbol table:

I think I looked right at it and didn't grok what it meant.

> 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?

Not up to me - I have Debian's gnat packages installed.  Is this
documented, i.e. it should be considered a bug in those packages?

-- 
Daniel Jacobowitz
CodeSourcery

Re: New Ada failure

[Joel Brobecker]

> > 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?
> 
> Not up to me - I have Debian's gnat packages installed.  Is this
> documented, i.e. it should be considered a bug in those packages?

As far as I am concerned, I think it should be considered a bug.
However, I am not sure it is documented. Is there a speciic place where
it should be documented? Perhaps in the INSTALL or README of GCC?
I'll ask around at AdaCore.

-- 
Joel

Re: New Ada failure

[Joel Brobecker]

Hello Daniel,

> Not up to me - I have Debian's gnat packages installed.  Is this
> documented, i.e. it should be considered a bug in those packages?

I have now checked in a patch in GCC that explains that the GNAT
runtime should not be stripped. Would you mind filing a bug with
the Debian maintainers? I'm not familiar with the procedure. You
may want to mention to them that they should be able to build the
runtime without -g. There is a flag for it, probably LIBGNATCFLAGS
or some such. The makefiles will know to force -g -O1 for the few
units we need.

-- 
Joel

Re: New Ada failure

[Daniel Jacobowitz]

On Fri, Jan 05, 2007 at 06:54:33PM +0400, Joel Brobecker wrote:
> I have now checked in a patch in GCC that explains that the GNAT
> runtime should not be stripped. Would you mind filing a bug with
> the Debian maintainers? I'm not familiar with the procedure. You
> may want to mention to them that they should be able to build the
> runtime without -g. There is a flag for it, probably LIBGNATCFLAGS
> or some such. The makefiles will know to force -g -O1 for the few
> units we need.

Done, though we may take a different approach.  Meanwhile, should
we let the test fail for this case, or mark it UNSUPPORTED?

-- 
Daniel Jacobowitz
CodeSourcery

Re: New Ada failure

[Joel Brobecker]

> > I have now checked in a patch in GCC that explains that the GNAT
> > runtime should not be stripped. Would you mind filing a bug with
> > the Debian maintainers? I'm not familiar with the procedure. You
> > may want to mention to them that they should be able to build the
> > runtime without -g. There is a flag for it, probably LIBGNATCFLAGS
> > or some such. The makefiles will know to force -g -O1 for the few
> > units we need.
> 
> Done, though we may take a different approach.  Meanwhile, should
> we let the test fail for this case, or mark it UNSUPPORTED?

I am of two hearts with this. On the one hand, yes, the test should
be unsupported if the GNAT runtime is malformed. However, a bug in
our lookup would yield the same type of failure, and thus marking
the testcase as unsuported would hide that.

I would lean towards making it UNSUPPORTED, since the chances of
the lookup failing are fairly remote (or many other testcases
will badly fail).

If we decide to make it unsupported, would you mind taking care of it?
I cannot reproduce your problem, and my attempts at building the FSF
compiler from sources have miserably failed...

Thank you,
-- 
Joel