This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: i386 int3 handling, running vs stepping
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"));
}