From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6422 invoked by alias); 7 Oct 2008 16:31:39 -0000 Received: (qmail 6374 invoked by uid 22791); 7 Oct 2008 16:31:38 -0000 X-Spam-Check-By: sourceware.org Received: from igw2.br.ibm.com (HELO igw2.br.ibm.com) (32.104.18.25) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 07 Oct 2008 16:30:55 +0000 Received: from d24relay01.br.ibm.com (unknown [9.8.31.16]) by igw2.br.ibm.com (Postfix) with ESMTP id 98B6917F5AA for ; Tue, 7 Oct 2008 13:14:38 -0300 (BRT) Received: from d24av01.br.ibm.com (d24av01.br.ibm.com [9.18.232.46]) by d24relay01.br.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id m97GUenh2105496 for ; Tue, 7 Oct 2008 13:30:40 -0300 Received: from d24av01.br.ibm.com (loopback [127.0.0.1]) by d24av01.br.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m97GUmsg004032 for ; Tue, 7 Oct 2008 13:30:49 -0300 Received: from [9.8.5.252] ([9.8.5.252]) by d24av01.br.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m97GUifM003779 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Oct 2008 13:30:46 -0300 Subject: Re: [rfc] Simplify ppc64_sysv_abi_adjust_breakpoint_address From: Luis Machado Reply-To: luisgpm@linux.vnet.ibm.com To: Ulrich Weigand Cc: Daniel Jacobowitz , gdb-patches@sourceware.org In-Reply-To: <200805161253.m4GCrRqL011333@d12av02.megacenter.de.ibm.com> References: <200805161253.m4GCrRqL011333@d12av02.megacenter.de.ibm.com> Content-Type: text/plain Date: Tue, 07 Oct 2008 16:31:00 -0000 Message-Id: <1223397031.612.26.camel@gargoyle> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: 7bit 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: 2008-10/txt/msg00214.txt.bz2 Hi folks, Resurrecting this one... It seems we have a situation in which "ppc64_sysv_abi_adjust_breakpoint_address" is still required, in a way. Before removing this function, GDB was smart enough to know that the entry point of a 64-bit PPC binary is, in reality, a function descriptor, thus grabbing the correct breakpoint location from within that address and setting it correctly. After removing this function, GDB no longer knows that a specific address is a function descriptor, and places a breakpoint at a data section. The binary's code tries to fetch the correct address from the function descriptor's address and ends up fetching the breakpoint instruction, which makes no sense. So, i see two ways: 1 - Make GDB smart again, being able to determine if the address is of a function descriptor or not, basically the way i was before this patch. 2 - Assume the user knows what he's doing and that he knows where to place a breakpoint when using the address of a function descriptor. Regards, Luis On Fri, 2008-05-16 at 14:53 +0200, Ulrich Weigand wrote: > Daniel Jacobowitz wrote: > > On Thu, May 15, 2008 at 01:02:00AM +0200, Ulrich Weigand wrote: > > > Thus I'd propose to remove that code. Any objections? > > > > Hooray! I like this. > > Checked in as well. > > Thanks, > Ulrich >