From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29868 invoked by alias); 30 Mar 2013 21:03:11 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 29841 invoked by uid 89); 30 Mar 2013 21:03:03 -0000 X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_HOSTKARMA_NO,RCVD_IN_HOSTKARMA_YE,SPF_NEUTRAL autolearn=no version=3.3.1 Received: from balrog.mythic-beasts.com (HELO balrog.mythic-beasts.com) (93.93.130.6) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Sat, 30 Mar 2013 21:03:00 +0000 Received: from [93.93.130.49] (port=51151 helo=sphinx.mythic-beasts.com) by balrog.mythic-beasts.com with esmtp (Exim 4.72) (envelope-from ) id 1UM2vS-0002fb-2Q; Sat, 30 Mar 2013 21:02:58 +0000 Received: from richard (helo=localhost) by sphinx.mythic-beasts.com with local-esmtp (Exim 4.72) (envelope-from ) id 1UM2vR-00049Y-PG; Sat, 30 Mar 2013 21:02:57 +0000 Date: Sat, 30 Mar 2013 21:03:00 -0000 From: Richard Smith To: Jan Kratochvil cc: gdb@sourceware.org Subject: Re: Backtraces broken on i386 by unorthodox encoding of push %ebp In-Reply-To: <20130330195008.GA11994@host2.jankratochvil.net> Message-ID: References: <20130330195008.GA11994@host2.jankratochvil.net> User-Agent: Alpine 2.02 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-BlackCat-Spam-Score: -18 X-SW-Source: 2013-03/txt/msg00087.txt.bz2 Jan Kratochvil wrote: > You should always provide unwind information and then it is irrelevant which > instructions and/or which their coding you use. Yes, you're right, I could quite easily. But a design criterion for this project is that it is easy for third-parties to produce backtraces from production code (i.e. once debugging information has been stripped). I think on balance, I should just fix the prologue to use the one-byte push instruction. (My reluctance to do that was because the in question code is just-in-time compiled code produced by a lightweight compiler/assembler that says resident in memory. I'm not keen to change the assembler component from the upstream version as the change to fix it looks more intrusive than you might imagine.) Joel Brobecker wrote: > But if he cannot get the unwind information with the > binary, it might indeed be easy enough to improve the > prologue analyzer for x86. On x86_64, on the other hand, > we made the conscious design decision to rely more on > unwind info, so it's a little more questionable whether > we'd want to do that for this target. > > The thing I wanted to add to Richard is that there is a > very high chance that the only way to get this fixed in > GDB is by submitting a patch himself (to gdb-patches). I'll certainly take a look at it to see if it's as straightforward as it seems. However, I expect the same problem will arise on x86_64, and I can understand not wanting to complicate unnecessarily its prologue analyzer. Richard