This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: How does gdb handle syscall restarting on Linux?
- From: Pedro Alves <pedro at codesourcery dot com>
- To: gdb at sourceware dot org
- Cc: Scott Long <smxlong at gmail dot com>
- Date: Thu, 26 Mar 2009 00:19:54 +0000
- Subject: Re: How does gdb handle syscall restarting on Linux?
- References: <a348a4b0903251705k463f7810pcea9cee736dbb526@mail.gmail.com>
See src/gdb/i386-linux-tdep.c:i386_linux_write_pc.
On Thursday 26 March 2009 00:05:02, Scott Long wrote:
> I'm developing a lightweight process control library for Linux,
> essentially a wrapper around ptrace() but with the ability to inject
> code into processes for instrumentation ("attach and profile"
> functionality). I've hit an issue which I'm sure gdb must also
> encounter, and was wondering how gdb deals with it.
>
> I've already perused the gdb source, but can't find the relevant code.
>
> What I am observing is that I attach to a process, wait for it to
> stop, poke some code into memory as well as a stack frame, twiddle ESP
> and EIP, then restart the process.
>
> The symptom is that the process attempts to execute from an EIP value
> which is 2 less than the value I set it to. In this case, this EIP
> value points to an invalid address, and the inferior process crashes
> when I attempt to restart it.
>
> What I believe has happened is that the SIGSTOP which was delivered
> when I attached, interrupted a system call in the inferior process.
> The kernel is now trying to restart this system call by adjusting EIP
> by -2 (the size of an "int 0x80" instruction).
>
> How can I detect this situation, and more importantly, how do I handle
> it? A few thoughts have occurred to me.
>
> 1. I could check if the current EIP is somewhere in the vDSO region,
> and if so, assume that I've interrupted a system call. Restart the
> process and try again, until I'm not in the vDSO any more.
>
> 2. Similar to 1, but "keep on trucking" by adding 2 to my EIP value to
> account for the -2 the kernel will set -- then adjust the original EIP
> by -2 as if the kernel had done it.
>
> 3. Ignore the issue, and place a pad page full of NOP instructions
> immediately prior to the injected code. Now it doesn't matter than EIP
> is off, it will just follow the NOPs until it hits the real code.
>
> My concern is that I don't want to damage process semantics by doing
> something invalid, like causing a system call or a signal to silently
> get lost.
>
> It seems like gdb MUST be able to deal with this. If there is code in
> gdb which does this, I'd love to have a pointer to it, to avoid
> wasting anybody's time here.
>
> Thanks,
> Scott Long
>
--
Pedro Alves