1

看一看：

    (gdb) x/x $esp
       0xb720a621:  0x00000000
    (gdb) info register eflags
       eflags         0x200286  [ PF SF IF ID ]
    (gdb) x/5i $pc
    => 0x15a965d <tables+11901>:    popf   
       0x15a965e <tables+11902>:    mov    $0xd7fb0aa3,%ecx
       0x15a9663 <tables+11907>:    ret    $0x849d
       0x15a9666 <tables+11910>:    xor    (%ebx),%esi
       0x15a9668 <tables+11912>:    aam    $0x78
    (gdb) stepi
       0x015a965e in tables () from /usr/local/apache2/modules/libphp5.so
    (gdb) info register eflags
       eflags         0x202 [ IF ]
    (gdb) stepi
       0x015a9663 in tables () from /usr/local/apache2/modules/libphp5.so
    (gdb) info register eflags
       eflags         0x302 [ TF IF ]

不确定为什么在下一条指令后设置 TF。

4

1 回答 1

1

我相信这是一个内核错误。TF单步时内核必须设置，但用户模式也可能正在修改TF。为了处理这个问题，内核尝试维护 who set TF：

    /* Set TF on the kernel stack.. */
    regs->flags |= X86_EFLAGS_TF;

    /*
     * ..but if TF is changed by the instruction we will trace,
     * don't mark it as being "us" that set it, so that we
     * won't clear it by hand later.
     *
     * Note that if we don't actually execute the popf because
     * of a signal arriving right now or suchlike, we will lose
     * track of the fact that it really was "us" that set it.
     */
    if (is_setting_trap_flag(child, regs)) {
            clear_tsk_thread_flag(child, TIF_FORCED_TF);
            return 0;
    }

请注意，它甚至承认某些极端情况可能会使其迷失方向。更糟糕的是，is_setting_trap_flag它只检查指令是否会修改TF，而不检查它是否真的在设置它：

    switch (opcode[i]) {
    /* popf and iret */
    case 0x9d: case 0xcf:
            return 1;

因此，TF即使它已被清除，它也会标记为用户设置。如果它是由内核设置的get_flags，它将尝试屏蔽TF如下：

    /*
     * If the debugger set TF, hide it from the readout.
     */
    if (test_tsk_thread_flag(task, TIF_FORCED_TF))
            retval &= ~X86_EFLAGS_TF;

由于TIF_FORCED_TF已被错误地清除，此条件将不成立，因此TF实际上已由内核为单步执行设置的值将返回给调试器。

我认为这可以通过修改来解决，is_setting_trap_flag以便它检查堆栈中标志的新值，并且仅在实际设置1时才返回。TF

于 2012-12-21T15:02:59.200 回答