Re: Is nexti confused by pushq?

[Andrew Burgess <andrew dot burgess at embecosm dot com>]

* dwk <dwks42@gmail.com> [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 <dgriffiths@undo.io> 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
> > >
> >