From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4321 invoked by alias); 1 Mar 2007 21:56:54 -0000 Received: (qmail 4308 invoked by uid 22791); 1 Mar 2007 21:56:50 -0000 X-Spam-Check-By: sourceware.org Received: from igw1.br.ibm.com (HELO igw1.br.ibm.com) (32.104.18.24) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 01 Mar 2007 21:56:44 +0000 Received: from mailhub1.br.ibm.com (mailhub1 [9.18.232.109]) by igw1.br.ibm.com (Postfix) with ESMTP id 2CA781481F1 for ; Thu, 1 Mar 2007 18:49:12 -0300 (BRT) Received: from d24av02.br.ibm.com (d24av02.br.ibm.com [9.18.232.47]) by mailhub1.br.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l21LufII1601730 for ; Thu, 1 Mar 2007 18:56:41 -0300 Received: from d24av02.br.ibm.com (loopback [127.0.0.1]) by d24av02.br.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l21LtawQ017989 for ; Thu, 1 Mar 2007 18:55:37 -0300 Received: from dyn532128.br.ibm.com (dyn532128.br.ibm.com [9.18.238.251]) by d24av02.br.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l21Ltabb017986; Thu, 1 Mar 2007 18:55:36 -0300 Subject: Re: [PATCH 24700] From: Thiago Jung Bauermann To: Daniel Jacobowitz Cc: Jose Flavio Aguilar Paulino , gdb-patches@sourceware.org In-Reply-To: <20070301204046.GA5989@caradoc.them.org> References: <1172777198.10229.11.camel@kadinsky.prado> <20070301183700.GA19796@caradoc.them.org> <1172783136.10229.28.camel@kadinsky.prado> <20070301204046.GA5989@caradoc.them.org> Content-Type: text/plain; charset=utf-8 Date: Thu, 01 Mar 2007 21:56:00 -0000 Message-Id: <1172786200.31150.11.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes 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: 2007-03/txt/msg00006.txt.bz2 Hi, I'm working with Flávio on this issue... On Thu, 2007-03-01 at 15:40 -0500, Daniel Jacobowitz wrote: > On Thu, Mar 01, 2007 at 05:05:36PM -0400, Jose Flavio Aguilar Paulino wrote: > > The problem was that 'ppc64_linux_convert_from_func_ptr_addr()' first wanted to > > make sure that the function pointer for 'malloc()' pointed into an .opd section > > before it was 'dereferenced' It used 'target_section_by_addr()' to do the > > search, and the section containing the PLT pointed to by the function pointer > > was not in the section table being searched. But there is another section > > table. > > Actually, there's a ton of section tables - this is an organizational > problem in GDB. Originally they all meant different things. > > Does using find_pc_section instead work in all cases? In the testcase mentioned here, GDB wants to allocate memory in the inferior so that it can set the string's value. It's GDB that's calling malloc and not the inferior, so the inferior's PC is not anywhere near malloc (unless we're lucky), as far as I know... -- []'s Thiago Jung Bauermann Software Engineer IBM Linux Technology Center