From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2282 invoked by alias); 19 Oct 2004 02:23:49 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 1995 invoked from network); 19 Oct 2004 02:23:48 -0000 Received: from unknown (HELO mclean.mail.mindspring.net) (207.69.200.57) by sourceware.org with SMTP; 19 Oct 2004 02:23:48 -0000 Received: from user-119a90a.biz.mindspring.com ([66.149.36.10] helo=berman.michael-chastain.com) by mclean.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1CJjf9-0004SG-00; Mon, 18 Oct 2004 22:23:47 -0400 Received: from mindspring.com (localhost [127.0.0.1]) by berman.michael-chastain.com (Postfix) with SMTP id 3553C4B102; Mon, 18 Oct 2004 22:24:04 -0400 (EDT) Date: Tue, 19 Oct 2004 13:28:00 -0000 From: Michael Chastain To: jonathan.m.hanson@intel.com, gdb@sources.redhat.com Subject: Re: Accessing x86 general-purpose registers Message-ID: <41747AC2.nailJWG1NGL1K@mindspring.com> References: In-Reply-To: User-Agent: nail 10.8 6/28/04 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2004-10/txt/msg00352.txt.bz2 "Hanson, Jonathan M" wrote: > In include/asm-i386/user.h is a structure called struct user > with a member struct user_pt_regs, which is where GDB gets the general > purpose register information for a program being debugged. I can see > nowhere else in the kernel where this structure is written to. How is > this information populated? Is there a way I can access this structure > from the kernel itself? It's been a while since I've read this code (others have probably seen it a lot more recently) -- Look for the system call entry code in arch/i386/kernel/entry.S, particularly ENTRY(system_call) and ENTRY(sysenter_entry). When a program makes a system call, the process enters the kernel. It helps to think of the kernel as a big shared library rather than a separate process. Nearly the first thing that the process does is to save the values of all the user-space registers with the SAVE_ALL macro. That's how the user register structure is populated. The user register structure is valid only if the target process is inside the kernel. If the target process is not inside the kernel (like, it's doing normal computation), then its registers are not available in this way. Most system calls operate only on the process that made the call, and that process is guaranteed to be executing kernel code if it's inside the kernel, kind of trivially. ptrace(2) is the only system call that I know that operates on a different process, so ptrace(2) has to jump through hoops to access registers and memory in a different process. Hope this helps, Michael Chastain