From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12636 invoked by alias); 30 Dec 2011 03:30:51 -0000 Received: (qmail 12619 invoked by uid 22791); 30 Dec 2011 03:30:49 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,TW_BJ X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 30 Dec 2011 03:30:36 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id DA0562BAFED; Thu, 29 Dec 2011 22:30:35 -0500 (EST) 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 FBh+c4VxuE-f; Thu, 29 Dec 2011 22:30:35 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 40EFD2BAFDE; Thu, 29 Dec 2011 22:30:35 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id 6EDF8145615; Thu, 29 Dec 2011 19:30:20 -0800 (PST) Date: Fri, 30 Dec 2011 08:46:00 -0000 From: Joel Brobecker To: Jan Kratochvil Cc: Mark Kettenis , gdb-patches@sourceware.org Subject: Re: [patch] Fix gdb.cp/gdb2495.exp regression with gcc-4.7 #3 Message-ID: <20111230033020.GA20473@adacore.com> References: <20111222202047.GA16110@host2.jankratochvil.net> <20111227045606.GE23376@adacore.com> <20111228161208.GB10556@host2.jankratochvil.net> <20111228180148.GA18057@host2.jankratochvil.net> <201112282009.pBSK9LHn029918@glazunov.sibelius.xs4all.nl> <20111229231251.GA27794@host2.jankratochvil.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111229231251.GA27794@host2.jankratochvil.net> User-Agent: Mutt/1.5.20 (2009-06-14) 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: 2011-12/txt/msg00897.txt.bz2 > As ON_STACK is a valid option sure one may prefer to convert all the > archs to ON_STACK instead of fixing AT_ENTRY_POINT; not preferred by > me TBH. I don't understand why, though. ON_STACK seems to be perfect, as we control exactly what's there, and we know we're not going to interfere with the rest of the code. Are there any situation where ON_STACK wouldn't be possible? I know that on some architectures such as VxWorks, where objfiles are already loaded in memory, and where memory is shared by all processes[1], there is no concept of "entry point". I have put in my TODO list to see if I can get rid of the last use of AT_SYMBOL (in mips-tdep.c) and convert it to ON_STACK. > 2011-12-30 Jan Kratochvil > > Fix regression for gdb.cp/gdb2495.exp with gcc-4.7. > * arch-utils.c (displaced_step_at_entry_point): Incrase BP_LEN skip to > 3 times. > * infcall.c (call_function_by_hand) : Move it upwards and > fall through into AT_ENTRY_POINT. > (call_function_by_hand) : New variable bp_len. Adjust > DUMMY_ADDR with it. > * ppc-linux-tdep.c (ppc_linux_displaced_step_location): Increase > PPC_INSN_SIZE skip to 3 times. I keep staring at the diff, and I can't figure out how the AT_SYMBOL case is falling through, or why it would be necessary. The lack of understading why is probably related to the fact that I may still have an incorrect understanding of the situation. I think that either way, it's better to have the dummy calling address at a location where there is no unwinding information. ON_STACK seems to be a better place to guaranty that. But that being said, making sure that, for AT_ENTRY_POINT, the dummy calling address is indeed our entry point cannot make things worse. > dummy_addr = gdbarch_convert_from_func_ptr_addr (gdbarch, > dummy_addr, > ¤t_target); > + /* A call dummy always consists of just a single breakpoint, > + so it's address is the same as the address of the dummy. */ ^^^ its > + } > + /* FALLTHROUGH */ > + case AT_ENTRY_POINT: Is this really a FALLTHROUGH? > + Therefore, we use the second byte (approximately, > + alignments depending on GDBARCH). It does not matter if it > + is placed inside the very first instruction, nothing tries > + to execute it. */ I can't remember if you explicitly decided to use the second byte and then changed your mind, or whether this is a typo from the fact that the breakpoint instruction on x86 is 1 byte long? Suggest replacing with: Therefore, we adjust the return address by the length of a breakpoint, guaranteeing that the unwinder finds the correct function as the caller. -- Joel