More "catch assert" Ada failures

More "catch assert" Ada failures

[Daniel Jacobowitz]

Debian now has a libgnat-4.1-dbg package which includes complete
debugging information for libgnat; this should let GDB handle
exception and assertion catchpoints.  A couple of the tests fail
though:

Unable to break on 'system__assertions__raise_assert_failure' in this
configuration.

But:

(gdb) b system__assertions__raise_assert_failure
Breakpoint 2 at 0x2aaaaae86530: file s-assert.adb, line 42.

(gdb) b 'system.assertions.raise_assert_failure'
Can't find member of namespace, class, struct, or union named "system.assertions.raise_assert_failure"

The debug info says "system.assertions.raise_assert_failure" in
DW_AT_name and tab completion finds that, but we can't breakpoint it;
and looking up the mangled double-underscore form only finds the
minimal symbol.  What do you expect to happen here?

-- 
Daniel Jacobowitz
CodeSourcery

Re: More "catch assert" Ada failures

[Joel Brobecker]

> Debian now has a libgnat-4.1-dbg package which includes complete
> debugging information for libgnat; this should let GDB handle
> exception and assertion catchpoints.  A couple of the tests fail
> though:
> 
> Unable to break on 'system__assertions__raise_assert_failure' in this
> configuration.

I indeed see some FAILs on that test, but ldd reports that the program
is still linked against libgnat-4.1.so.1, not the one installed in
/usr/lib/debug/usr/lib. I tried setting up symbolic links from one to
the other, but then the compiler crashes. Did you run the testsuite
with some specific switches?

-- 
Joel

Re: More "catch assert" Ada failures

[Daniel Jacobowitz]

On Mon, Jun 04, 2007 at 08:50:09AM -0700, Joel Brobecker wrote:
> > Debian now has a libgnat-4.1-dbg package which includes complete
> > debugging information for libgnat; this should let GDB handle
> > exception and assertion catchpoints.  A couple of the tests fail
> > though:
> > 
> > Unable to break on 'system__assertions__raise_assert_failure' in this
> > configuration.
> 
> I indeed see some FAILs on that test, but ldd reports that the program
> is still linked against libgnat-4.1.so.1, not the one installed in
> /usr/lib/debug/usr/lib. I tried setting up symbolic links from one to
> the other, but then the compiler crashes. Did you run the testsuite
> with some specific switches?

You need to configure with --prefix=/usr, and then GDB will pick up
files in /usr/lib/debug automatically.  I get:

FAIL: gdb.ada/catch_ex.exp: insert catchpoint on failed assertions
FAIL: gdb.ada/catch_ex.exp: info break, second run
FAIL: gdb.ada/catch_ex.exp: continuing to failed assertion
FAIL: gdb.ada/catch_ex.exp: continuing to unhandled exception (the
program exited)
FAIL: gdb.ada/catch_ex.exp: continuing to program completion (the
program is no longer running)

Without that I get twelve failures and no passes.

-- 
Daniel Jacobowitz
CodeSourcery

Re: More "catch assert" Ada failures

[Joel Brobecker]

> > > Unable to break on 'system__assertions__raise_assert_failure' in this
> > > configuration.

OK, thanks to Daniel's help, I'm able to reproduce the issue. The issue
in this case is that the name attributed for the entity is not following
the GNAT encoding:

     <1><8e990>: Abbrev Number: 9 (DW_TAG_subprogram)
         DW_AT_sibling     : <8e9b7>
         DW_AT_external    : 1
         DW_AT_name        : (indirect string, offset: 0x48349): system.assertions.raise_assert_failure
         DW_AT_decl_file   : 2
         DW_AT_decl_line   : 42
         DW_AT_low_pc      : 0x1a73a0
         DW_AT_high_pc     : 0x1a73d8
         DW_AT_frame_base  : 0x857ee        (location list)

The dots should actually be "__". Not sure why this is happening,
however. I'll see if I can get a hint or two from my compiler collegues...

-- 
Joel

Re: More "catch assert" Ada failures

[Joel Brobecker]

> OK, thanks to Daniel's help, I'm able to reproduce the issue. The issue
> in this case is that the name attributed for the entity is not following
> the GNAT encoding:
> 
>      <1><8e990>: Abbrev Number: 9 (DW_TAG_subprogram)
>          DW_AT_sibling     : <8e9b7>
>          DW_AT_external    : 1
>          DW_AT_name        : (indirect string, offset: 0x48349): system.assertions.raise_assert_failure
>          DW_AT_decl_file   : 2
>          DW_AT_decl_line   : 42
>          DW_AT_low_pc      : 0x1a73a0
>          DW_AT_high_pc     : 0x1a73d8
>          DW_AT_frame_base  : 0x857ee        (location list)
> 
> The dots should actually be "__". Not sure why this is happening,
> however. I'll see if I can get a hint or two from my compiler collegues...

With the help of Eric Botcazou, we determined GCC built straight from
the FSF tree follows our encoding, and thus does not have the "__"
replaced by dots. So it looks like it's something that the Debian
version of GCC might be doing differently. Apparently, the name
attribute generation is generated by:

  /* Generate a DW_AT_name attribute given some string value to be included as
     the value of the attribute.  */

  static void
  add_name_attribute (dw_die_ref die, const char *name_string)
  {
    if (name_string != NULL && *name_string != 0)
      {
        if (demangle_name_func)
          name_string = (*demangle_name_func) (name_string);

        add_AT_string (die, DW_AT_name, name_string);
      }
  }

In our case (GNAT compiler), demangle_name_func is NULL, so we
emit the encoded name without any modification. Maybe that's
where Debian GCC does things differently?

-- 
Joel

Re: More "catch assert" Ada failures

[Daniel Jacobowitz]

On Mon, Jun 04, 2007 at 02:31:54PM -0700, Joel Brobecker wrote:
> With the help of Eric Botcazou, we determined GCC built straight from
> the FSF tree follows our encoding, and thus does not have the "__"
> replaced by dots. So it looks like it's something that the Debian
> version of GCC might be doing differently. Apparently, the name
> attribute generation is generated by:
> 
>   /* Generate a DW_AT_name attribute given some string value to be included as
>      the value of the attribute.  */
> 
>   static void
>   add_name_attribute (dw_die_ref die, const char *name_string)
>   {
>     if (name_string != NULL && *name_string != 0)
>       {
>         if (demangle_name_func)
>           name_string = (*demangle_name_func) (name_string);
> 
>         add_AT_string (die, DW_AT_name, name_string);
>       }
>   }
> 
> In our case (GNAT compiler), demangle_name_func is NULL, so we
> emit the encoded name without any modification. Maybe that's
> where Debian GCC does things differently?

It's got to be something else; nothing in this package calls
dwarf2out_set_demangle_name_func.  But add_name_attribute is called
with the result of dwarf2_name which comes from decl_printable_name.
I'd always expect that to give the dotted form...

Aha:

2006-10-31  Eric Botcazou  <ebotcazou@adacore.com>
            Nicolas Setton  <setton@adacore.com>
            Olivier Hainque  <hainque@adacore.com>
            Gary Dismukes  <dismukes@adacore.com>

	...

        * misc.c (gnat_dwarf_name): New function.
        (LANG_HOOKS_DWARF_NAME): Define to gnat_dwarf_name.
        (gnat_post_options): Add comment about structural alias
	analysis.
        (gnat_parse_file): Do not call cgraph_optimize here.
        (LANG_HOOKS_WRITE_GLOBALS): Define to
	gnat_write_global_declarations.

Nothing before there is going to put the mangled name in DWARF info.
I don't know if that means 4.2 or 4.3.

-- 
Daniel Jacobowitz
CodeSourcery