Re: Is nexti confused by pushq?
Andrew Burgess <[email protected]>
| Newsgroups | gmane.comp.gdb.devel |
|---|---|
| Message-ID | <[email protected]> |
* dwk <[email protected]> [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 <[email protected]> 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 <https://undo.io> | 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 > > > > >