From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18034 invoked by alias); 30 Dec 2011 10:39:45 -0000 Received: (qmail 18022 invoked by uid 22791); 30 Dec 2011 10:39:44 -0000 X-SWARE-Spam-Status: No, hits=-2.7 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO glazunov.sibelius.xs4all.nl) (83.163.83.176) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 30 Dec 2011 10:39:30 +0000 Received: from glazunov.sibelius.xs4all.nl (kettenis@localhost [127.0.0.1]) by glazunov.sibelius.xs4all.nl (8.14.5/8.14.3) with ESMTP id pBUAd1is021411; Fri, 30 Dec 2011 11:39:01 +0100 (CET) Received: (from kettenis@localhost) by glazunov.sibelius.xs4all.nl (8.14.5/8.14.3/Submit) id pBUAcxQS004801; Fri, 30 Dec 2011 11:38:59 +0100 (CET) Date: Fri, 30 Dec 2011 11:11:00 -0000 Message-Id: <201112301038.pBUAcxQS004801@glazunov.sibelius.xs4all.nl> From: Mark Kettenis To: brobecker@adacore.com CC: jan.kratochvil@redhat.com, gdb-patches@sourceware.org In-reply-to: <20111230033020.GA20473@adacore.com> (message from Joel Brobecker on Fri, 30 Dec 2011 07:30:20 +0400) Subject: Re: [patch] Fix gdb.cp/gdb2495.exp regression with gcc-4.7 #3 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> <20111230033020.GA20473@adacore.com> 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/msg00902.txt.bz2 > Date: Fri, 30 Dec 2011 07:30:20 +0400 > From: Joel Brobecker > > > 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. I believe it has always been the intention to make ON_STACK the default. See the comment by Andrew Cagney in mips-tdep.c. For some architectures it is the only viable option. I'll probably switch i386/amd64 to use ON_STACK, since it allows for some cleanups in the DICOS support. > Are there any situation where ON_STACK wouldn't be possible? I don't think so. > 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. That'd be good since mips-tdep.c seems to be the only one left that still uses AT_SYMBOL. Would be nice if we can remove that code. > > 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. The idea is that AT_SYMBOL will fall back on putting the call dummy breakpoint at the entry point if the magic symbol name isn't found. Currently this is achieved by having duplicated code. Jan's diff changes it in a FALLTHROUGH to make it more explicit. > 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. I'm still a little bit worried that Jan's approach is making additional assumptions. The chance that the 2nd instruction of the program will be executed again as part of the normal flow is probably not much higher than for the 1st instructions, but the 1st instruction could be a jump. And I know Jan has checked his diff on ia64, but there might be other architectures that have the concept of instruction bundles where jumping into the middle of a bundle doesn't work. I think I'd be in favour of switching as many targets as possible to ON_STACK, remove AT_SYMBOL and leave AT_ENTRY_POINT alone. But I don't feel too strongly about this. Targets that switch to ON_STACK won't be affected by assumptions in AT_ENTRY_POINT that turn out not to be true. And if we manage to switch all targets to ON_STACK, we can simply delete AT_ENTRY_POINT.