From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10240 invoked by alias); 26 Feb 2019 07:32:44 -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 9333 invoked by uid 89); 26 Feb 2019 07:32:44 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=pc, $pc, supplier, H*r:sk:gdb@sou X-HELO: mail-wr1-f48.google.com Received: from mail-wr1-f48.google.com (HELO mail-wr1-f48.google.com) (209.85.221.48) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 26 Feb 2019 07:32:42 +0000 Received: by mail-wr1-f48.google.com with SMTP id t18so12710612wrx.2 for ; Mon, 25 Feb 2019 23:32:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=embecosm.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=q8xHk45Bl+WD/c6AYJfRiQZQxeiK6gMMZ99SKgaVmD8=; b=NGw5LewnAEGd1v2kTx7DbfXyDsgz5Ya6SE0CYvHC8TtNhd1roC5nnM5oXl22MT0XcA nPxMubdL6LYRXRr4Jpmx8+Jj6qfMe9yE6kdLCWGLEMxuX7Fae+QDcsrw5+4qCDqdj6CR Kja5sLZ5sli+0PsvP4KiWe9MCrlvkPcjHJVF26xXtyd6fb5nI/SdtkTNZjI0ZCKSrQNz sg5at8sxSVkxMjS0Nkii3B0bpqn8m3BmtrAv+Fabdk214rxQoMbiEbiRqvZiJNa+rwQ7 ZdFORozEI8nmNpOK49FBN6uNPDVfuUo2EhZyxdPciGYnRSOuHummA2Z58ovYGNyPPesP CScw== Return-Path: Received: from localhost (bzq-25-79-130.cust.bezeqint.net. [212.25.79.130]) by smtp.gmail.com with ESMTPSA id a62sm10489908wmf.47.2019.02.25.23.32.39 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 25 Feb 2019 23:32:39 -0800 (PST) Date: Tue, 26 Feb 2019 07:32:00 -0000 From: Andrew Burgess To: dwk Cc: David Griffiths , GDB Subject: Re: Is nexti confused by pushq? Message-ID: <20190226073236.GD10887@embecosm.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Fortune: Beware of a tall black man with one blond shoe. X-Editor: GNU Emacs [ http://www.gnu.org/software/emacs ] User-Agent: Mutt/1.9.2 (2017-12-15) X-IsSubscribed: yes X-SW-Source: 2019-02/txt/msg00064.txt.bz2 * dwk [2019-02-25 10:54:19 -0500]: > I encounter this frequently, although I don't have a minimal case yet > either. I think it may have something to do with symbol information, as > I've only encountered the case when symbol information is not present (as > in the example you gave). stepi always works but nexti sometimes turns into > a continue, I assumed because it was unable to figure out where the "next" > instruction was somehow in the absence of symbols. The problem here is that pushq changes the stack pointer, this is obviously interacting badly with the unwinder in some cases. If we consider the difference between 'stepi' and 'nexti' we will see what is going wrong. A 'stepi' simply single steps the machine. There's very little extra logic, it's just a single step. A 'nexti' however, steps the next instruction in the current function, stepping over function calls. The way this works is that when the 'nexti' is issued GDB caches the current frame-id, that is (roughly) function entry $pc, and the frame base pointer (related to $sp at entry to the function). Once this is cached GDB single steps, and after each step it checks the current frame-id. If the frame-id has changed then GDB believes we have entered a new (nested) function, places a breakpoint at the return address, and then continues. Once we hit the breakpoint we should be back in the original frame and we have completed the 'nexti'. Now the problem comes if when we single step over the 'pushq' the frame-id changes, if this happens GDB gets confused and then continues. To check this you should try walking over your problem code using 'stepi', and at each step run the 'bt' command. What you'll see is that as you step over the 'pushq' the backtrace will change in someway, this indicates the change in frame-id that is causing problems for you. Of course, this doesn't solve the problem for you, but at least you know what's going wrong now :) Thanks, Andrew > > dwk > > On Mon, Feb 25, 2019, 10:41 AM David Griffiths wrote: > > > Hi, when I get to the following instructions: > > > > 0x00007fffe192413e: rex.W pushq 0x28(%rsp) > > 0x00007fffe1924143: rex.W popq (%rsp) > > 0x00007fffe1924147: callq 0x00007fffe1045de0 > > > > and do "nexti" at the first, it doesn't stop at the second but instead acts > > as though I'd done "continue". For some reason I can't reproduce with a > > little test though. > > > > (gdb 8.1 on Ubuntu 16.04) > > > > BTW I'm doing nexti programmatically and trying to avoid looking at the > > next instruction to decide whether to do stepi or nexti. > > > > Cheers, > > > > David > > > > -- > > > > David Griffiths, Senior Software Engineer > > > > Undo | Resolve even the most challenging software > > defects > > with software flight recorder technology > > > > Software reliability report: optimizing the software supplier and customer > > relationship > > < > > https://info.undo.io/software-reliability-report-optimizing-supplier-and-customer-relationship > > > > >