From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3609 invoked by alias); 4 Jun 2007 21:30:57 -0000 Received: (qmail 3593 invoked by uid 22791); 4 Jun 2007 21:30:47 -0000 X-Spam-Check-By: sourceware.org Received: from nile.gnat.com (HELO nile.gnat.com) (205.232.38.5) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 04 Jun 2007 21:30:45 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-nile.gnat.com (Postfix) with ESMTP id 3067D48CDE6 for ; Mon, 4 Jun 2007 17:30:43 -0400 (EDT) Received: from nile.gnat.com ([127.0.0.1]) by localhost (nile.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 20128-01-7 for ; Mon, 4 Jun 2007 17:30:43 -0400 (EDT) Received: from joel.gnat.com (unknown [70.71.0.212]) by nile.gnat.com (Postfix) with ESMTP id BFD9C48CE1F for ; Mon, 4 Jun 2007 17:30:42 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 489F2E7B4F; Mon, 4 Jun 2007 14:31:54 -0700 (PDT) Date: Mon, 04 Jun 2007 21:30:00 -0000 From: Joel Brobecker To: gdb@sourceware.org Subject: Re: More "catch assert" Ada failures Message-ID: <20070604213154.GP3761@adacore.com> References: <20070604130204.GA31142@caradoc.them.org> <20070604155009.GF3761@adacore.com> <20070604160600.GA8815@caradoc.them.org> <20070604190727.GM3761@adacore.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070604190727.GM3761@adacore.com> User-Agent: Mutt/1.4.2.2i Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2007-06/txt/msg00035.txt.bz2 > 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