Re: "finish" command leads to SIGTRAP

[Pedro Alves <palves@redhat.com>]

On 02/21/2019 03:54 PM, David Griffiths wrote:
> It's something to do with the nature of single stepping through a "popfq"
> instruction. Given the following instructions:

I assume you have a pushf somewhere earlier?

> 
>    0x7fffe104638f:    add    $0x8,%rsp
>    0x7fffe1046393:    popfq
>    0x7fffe1046394:    pop    %rbp
>    0x7fffe1046395:    jmpq   *%rax
> 
> If I set a breakpoint at the first of that set and single step through, I
> end up with:
> 
> eflags         0x346    [ PF ZF TF IF ]
> 
> but if I set a breakpoint on the last instruction and avoid single stepping
> I get:
> 
> eflags         0x246    [ PF ZF IF ]
> 
> and I think it's that TF that is causing the SIGTRAP?

Same as <https://sourceware.org/bugzilla/show_bug.cgi?id=13508> ?

I can reproduce that here, on Fedora 27 / Linux 4.17.17-100.fc27.x86_64.

Sounds like PTRACE_SINGLESTEP enables TF, which then causes pushf to push
the state with TF set.  And then popf pops restores that TF-enabled state.

I'd think this is a kernel bug, in the same vein as the signal issue
I mentioned below (in which TF would get stuck when you stepped into
a signal handler, or something like that).  The kernel could have special
handling for pushf, emulating it instead of actually single-stepping it?

Maybe newer Linux kernels do something else.  Haven't tried.

I wonder what other kernels, like e.g., FreeBSD do here?

Guess if GDB is to workaround this, it'll have to either add
special treatment for this instruction (emulate, step over with a software
breakpoints, something like that), or clear TF manually after
single-stepping.  :-/

Thanks,
Pedro Alves

(please avoid top posting)

> 
> 
> On Thu, 21 Feb 2019 at 13:12, Pedro Alves <palves@redhat.com> wrote:
> 
>> Might be unrelated, but ISTR that there used to be a kernel bug
>> that would lead to the cpu's trace flag getting stuck set
>> when you step in a signal handler.  That would result in
>> SIGTRAP happening at every step from that point on.  Could
>> that be the case here?
>>
>> I'd look at "set debug displaced on" too.  Otherwise, it's a matter
>> at staring at the logs, and trying to understand what is happening.
>> Basically, "finish" sets a breakpoint at the caller and runs to it.
>> But all sorts of other things can happen behind the scenes.
>>