From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8378 invoked by alias); 25 Jan 2002 09:20:46 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 8337 invoked from network); 25 Jan 2002 09:20:44 -0000 Received: from unknown (HELO cerbere.u-strasbg.fr) (130.79.112.7) by sources.redhat.com with SMTP; 25 Jan 2002 09:20:44 -0000 Received: from laocoon (laocoon.u-strasbg.fr [130.79.112.72]) by cerbere.u-strasbg.fr (8.9.3/8.8.7) with ESMTP id KAA12194; Fri, 25 Jan 2002 10:20:36 +0100 Message-Id: <4.2.0.58.20020125093551.00a481f0@ics.u-strasbg.fr> X-Sender: muller@ics.u-strasbg.fr X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 25 Jan 2002 01:20:00 -0000 To: "Sarnath K - CTD, Chennai." , Pierre Muller From: Pierre Muller Subject: RE: "xbreak" command in GDB ? Cc: gdb@sources.redhat.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-SW-Source: 2002-01/txt/msg00296.txt.bz2 At 09:29 25/01/2002 , Sarnath K - CTD, Chennai. a écrit: > >Simply try > >./gdb ./gdb > >break main > >xbreak main > >disas main > > GDB never exits via the leaving point >of main() function, I suppose. >It exits via "quit_command" function. >I vaguely remember this ( when I was >browsing GDB source code.) So this test >might not reflect things correctly. >Correct me if I am wrong I didn't want to say that you should run the progream after. Simply comparing the address of the xbreak with the position of the ret instruction in the function disassembly is enough to show that you are right in saying that this command is buggy for i386 at least. Looking into source it apears that this is related to function find_pc_sect_partial_function because xbreak uses the returned endaddr value. function description says that /* Finds the "function" (text symbol) that is smaller than PC but greatest of all of the potential text symbols in SECTION. Sets *NAME and/or *ADDRESS conditionally if that pointer is non-null. If ENDADDR is non-null, then set *ENDADDR to be the end of the function (exclusive), but passing ENDADDR as non-null means that the function might cause symbols to be read. This function either succeeds or fails (not halfway succeeds). If it succeeds, it sets *NAME, *ADDRESS, and *ENDADDR to real information and returns 1. If it fails, it sets *NAME, *ADDRESS, and *ENDADDR to zero and returns 0. */ The exclusive attribute should be the reason why this works but the endaddress is simply set by cache_pc_function_high = BLOCK_END (SYMBOL_BLOCK_VALUE (f)); (cache_pc_function_high is copied into endaddr at function end) But I don't think that BLOCK_END should exclude any instruction, so its probably here that we should decrement but there is no code for function_epilogue in i386-tdep.c Pierre Muller Institut Charles Sadron 6,rue Boussingault F 67083 STRASBOURG CEDEX (France) mailto:muller@ics.u-strasbg.fr Phone : (33)-3-88-41-40-07 Fax : (33)-3-88-41-40-99