[Bug gdb/31702] New: 'nexti' on 'push' on x86_64 doesn't work correctly if there is no debug info

[Bug gdb/31702] New: 'nexti' on 'push' on x86_64 doesn't work correctly if there is no debug info

[arielmarcovitch at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=31702

            Bug ID: 31702
           Summary: 'nexti' on 'push' on x86_64 doesn't work correctly if
                    there is no debug info
           Product: gdb
           Version: 14.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: gdb
          Assignee: unassigned at sourceware dot org
          Reporter: arielmarcovitch at gmail dot com
  Target Milestone: ---

While debugging without debug info (the main difference I found was the `amd64
prologue` unwinder being used instead of `dwarf2`) I'm doing a `nexti`
instruction while standing on a 'push %reg' instruction. Either I don't get
control back after the command, or `gdb` tries to write a breakpoint to a bad
(unmapped) location and fails. When I do a `stepi` everything is ok.

My entire setup is a lot weirder but I can reproduce this part with the
following setup:

```
sudo gdb ls -p `pidof cat`
```
The reason I'm giving `gdb` the `ls` program instead of `cat` is so it doesn't
use the `dwarf` unwinder (this is closer to my situation)

Then travel until you get to some `push %reg' instruction and then do a `nexti`

Either I don't get control back, or the following message is displayed:
```
Cannot insert breakpoint 0.
Cannot access memory at address 0x20000
```

I started debugging it already and it seems to be something like this:

When we do a `nexti` we actually do first a single-step. Then we try to find
out whether we are after a subroutine call and add a breakpoint to the return
address.

In my case, when a more basic unwinder is used, `amd64 prologue`, we are
considered to have a different stack frame because of the push we did, and so
we try to put a breakpoint on the thing we think to be the return address and
it is of course not true at all.

Now, I see why this might be a hard problem to solve, as the unwinder can't
know all that. But maybe there is a simple solution I can't think of.

Thanks for the attention and the effort :)

-- 
You are receiving this mail because:
You are on the CC list for the bug.