Re: i386 int3 handling, running vs stepping

[Doug Evans <dje@google.com>]

On Mon, Feb 2, 2009 at 1:49 PM, Daniel Jacobowitz <drow@false.org> wrote:
> On Mon, Feb 02, 2009 at 12:03:13PM -0800, Doug Evans wrote:
>> On Sun, Feb 1, 2009 at 8:24 PM, Daniel Jacobowitz <drow@false.org> wrote:
>> > On Sun, Feb 01, 2009 at 03:38:04PM -0800, Doug Evans wrote:
>> >> I haven't looked into siginfo, but can gdb look at the insn?  [akin to
>> >> displaced stepping handling]
>> >
>> > I suppose, but I don't really see a point.
>>
>> Apologies, it's not clear what point you're referring to.
>>
>> I guess the issue is whether int3's in programs are supported by gdb,
>> and by supported I mean users can rely on gdb flagging a SIGTRAP when
>> they're executed.  As you say, there are people who take advantage of
>> this for hardwired breakpoints.
>
> Since it works today, and we know that people use it, I think we have
> no choice but to consider it supported.
>
>> There are various situations where gdb itself will singlestep code
>> (e.g., "step", "next", s/w watchpoints).  Can users expect to see the
>> SIGTRAP in these situations (and all others)?  And if the program is
>> being run by a script, can the script expect to see the SIGTRAP in all
>> cases?
>
> That's certainly not the case today.  If you want to make it work, and
> add a couple of tests for it, I've no objection - it seems a plausible
> thing to do.  But I would prefer that any solution did not involve
> reading the instruction at every step; that's quite slow, on a target
> where we otherwise do not need to.

Thanks.
I don't know when I'd have time to get to this, mostly I wanted to
make sure I understood why things are the way they are.

For reference sake, while looking into something else I was reminded
that the x86 linux port already looks at the insn being stepped.  Heh.
 :-)
[Without suggesting it's now a-priori ok to and add such reads to all ports.]
[Things like trust-readonly can speed this up too.]

static void
i386_linux_resume (ptid_t ptid, int step, enum target_signal signal)
{
  int pid = PIDGET (ptid);

  int request = PTRACE_CONT;

  if (step)
    {
      struct regcache *regcache = get_thread_regcache (pid_to_ptid (pid));
      ULONGEST pc;
      gdb_byte buf[LINUX_SYSCALL_LEN];

      request = PTRACE_SINGLESTEP;

      regcache_cooked_read_unsigned
        (regcache, gdbarch_pc_regnum (get_regcache_arch (regcache)), &pc);

      /* Returning from a signal trampoline is done by calling a
         special system call (sigreturn or rt_sigreturn, see
         i386-linux-tdep.c for more information).  This system call
         restores the registers that were saved when the signal was
         raised, including %eflags.  That means that single-stepping
         won't work.  Instead, we'll have to modify the signal context
         that's about to be restored, and set the trace flag there.  */

      /* First check if PC is at a system call.  */
      if (target_read_memory (pc, buf, LINUX_SYSCALL_LEN) == 0
          && memcmp (buf, linux_syscall, LINUX_SYSCALL_LEN) == 0)
        {
          ULONGEST syscall;
          regcache_cooked_read_unsigned (regcache,
                                         LINUX_SYSCALL_REGNUM, &syscall);

          /* Then check the system call number.  */
          if (syscall == SYS_sigreturn || syscall == SYS_rt_sigreturn)
            {
              ULONGEST sp, addr;
              unsigned long int eflags;

              regcache_cooked_read_unsigned (regcache, I386_ESP_REGNUM, &sp);
              if (syscall == SYS_rt_sigreturn)
                addr = read_memory_integer (sp + 8, 4) + 20;
              else
                addr = sp;

              /* Set the trace flag in the context that's about to be
                 restored.  */
              addr += LINUX_SIGCONTEXT_EFLAGS_OFFSET;
              read_memory (addr, (gdb_byte *) &eflags, 4);
              eflags |= 0x0100;
              write_memory (addr, (gdb_byte *) &eflags, 4);
            }
        }
    }

  if (ptrace (request, pid, 0, target_signal_to_host (signal)) == -1)
    perror_with_name (("ptrace"));
}