From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18300 invoked by alias); 26 Mar 2009 00:20:16 -0000 Received: (qmail 17764 invoked by uid 22791); 26 Mar 2009 00:20:15 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 26 Mar 2009 00:20:10 +0000 Received: (qmail 16866 invoked from network); 26 Mar 2009 00:19:55 -0000 Received: from unknown (HELO orlando) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 26 Mar 2009 00:19:55 -0000 From: Pedro Alves To: gdb@sourceware.org Subject: Re: How does gdb handle syscall restarting on Linux? Date: Thu, 26 Mar 2009 00:20:00 -0000 User-Agent: KMail/1.9.10 Cc: Scott Long References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200903260019.54288.pedro@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2009-03/txt/msg00162.txt.bz2 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