From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30819 invoked by alias); 25 Apr 2008 18:00:17 -0000 Received: (qmail 30773 invoked by uid 22791); 25 Apr 2008 18:00:14 -0000 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 25 Apr 2008 17:59:56 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id F2CAD2A9D7D for ; Fri, 25 Apr 2008 13:59:54 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ONhHDvXyg7gK for ; Fri, 25 Apr 2008 13:59:54 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 9B0DA2A9D7C for ; Fri, 25 Apr 2008 13:59:54 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 812C4E7ACD; Fri, 25 Apr 2008 10:59:52 -0700 (PDT) Date: Fri, 25 Apr 2008 19:00:00 -0000 From: Joel Brobecker To: gdb-patches@sourceware.org Subject: Re: [RFC/ia64-linux] pb with shared libraries when attaching to process Message-ID: <20080425175952.GA841@adacore.com> References: <20080425012331.GP1431@adacore.com> <20080425014746.GA10244@caradoc.them.org> <20080425023623.GB16580@adacore.com> <20080425032341.GA15147@caradoc.them.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="oyUTqETQ0mS9luUI" Content-Disposition: inline In-Reply-To: <20080425032341.GA15147@caradoc.them.org> User-Agent: Mutt/1.4.2.2i Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-04/txt/msg00577.txt.bz2 --oyUTqETQ0mS9luUI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-length: 2161 > > Looking deeper into this, the problem is that GDB determins that > > this symbol is in the .data section. The code that recognizes > > function descriptors for ia64 checks first that the associated > > section name is ".opd", or else checks the name of the symbol > > with is_vtable_name() (see ia64-tdep.c:ia64_convert_from_func_ptr_addr). > > > > I double checked /lib/ld-linux-ia64.so.2, and unless I'm mistaken, > > the debugger is correct. Our address is inside the .data section > > of the loader. There is no .opd section in sight. Eric Botcazou suggested that an address pointing to the .data section should never be some code because the .data section is not executable; So we could simply check the flags of our section, and if it doesn't have the CODE flag set, then assume it's a function descriptor. I have succesfully tested the following patch with gdb-6.8 (HEAD is having some issues causing the inferior to fail to start with a SIGILL at the moment - I'll look at that next). 2008-04-25 Joel Brobecker * ia64-tdep.c (ia64_convert_from_func_ptr_addr): Treat addresses pointing inside a non-executable section as function descriptors. Results before and after the patch: +------------+------------+----------------------------------------------------+ | FAIL | PASS | attach.exp: after attach2, reach tbreak postloop | | FAIL | PASS | attach.exp: after attach2, exit | | UNRESOLVED | PASS | attach.exp: before attach3, flush exec | | UNRESOLVED | PASS | attach.exp: attach when process' a.out not in cwd | | FAIL | PASS | attach.exp: c | +------------+------------+----------------------------------------------------+ The attached patch is something that I would consider for gdb-6.8. For gdb-head, I might even go one step farther and remove the check for the .opd section name just above, since the new check should handle the .opd section as well. I'm also wondering about the vtable-related symbols, but that's harder for me to verify... What do you think? -- Joel --oyUTqETQ0mS9luUI Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="fundesc.diff" Content-length: 682 Index: ia64-tdep.c =================================================================== --- ia64-tdep.c (revision 130268) +++ ia64-tdep.c (working copy) @@ -3328,6 +3328,12 @@ ia64_convert_from_func_ptr_addr (struct if (s && strcmp (s->the_bfd_section->name, ".opd") == 0) return read_memory_unsigned_integer (addr, 8); + /* If ADDR points to a section that is not executable, then it cannot + be pointing to a function. So it must be pointing to a function + descriptor. */ + if (s && (s->the_bfd_section->flags & SEC_CODE) == 0) + return read_memory_unsigned_integer (addr, 8); + /* There are also descriptors embedded in vtables. */ if (s) { --oyUTqETQ0mS9luUI--