From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32515 invoked by alias); 9 Oct 2008 17:57:25 -0000 Received: (qmail 32507 invoked by uid 22791); 9 Oct 2008 17:57:25 -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; Thu, 09 Oct 2008 17:56:38 +0000 Received: from d24relay01.br.ibm.com (unknown [9.8.31.16]) by igw2.br.ibm.com (Postfix) with ESMTP id 90FB917F66E for ; Thu, 9 Oct 2008 14:40:15 -0300 (BRT) Received: from d24av02.br.ibm.com (d24av02.br.ibm.com [9.18.232.47]) by d24relay01.br.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id m99HuNI82527402 for ; Thu, 9 Oct 2008 14:56:23 -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 m99HuXrH011570 for ; Thu, 9 Oct 2008 14:56:33 -0300 Received: from [9.18.199.202] ([9.18.199.202]) by d24av02.br.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m99HuWsv011529 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Oct 2008 14:56:33 -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: <200810091751.m99HpuoM001681@d12av02.megacenter.de.ibm.com> References: <200810091751.m99HpuoM001681@d12av02.megacenter.de.ibm.com> Content-Type: text/plain Date: Thu, 09 Oct 2008 17:57:00 -0000 Message-Id: <1223574985.5110.1.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/msg00297.txt.bz2 On Thu, 2008-10-09 at 19:51 +0200, Ulrich Weigand wrote: > Luis Machado wrote: > > > 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. > > I'm not sure exactly what situation you're refering to ... is this > about > break *0x..... > where the address that was manually specified refers to a function > descriptor instead of the function code? > > In that case, I'd tend to consider this user error -- if you use > hard-coded addresses, you should know what you're doing on the > platform. > > If this is about something else, could you show a command line > that does the wrong thing for you? > > Bye, > Ulrich > This is exactly about placing breakpoint on numberic addresses like "break *0x...". GDB used to do that correctly before that patch, but it doesn't anymore. So, maybe it's OK to consider this is something the user should be aware of... Luis