From: Michael Chastain <mec.gnu@mindspring.com>
To: jonathan.m.hanson@intel.com, gdb@sources.redhat.com
Subject: Re: Accessing x86 general-purpose registers
Date: Tue, 19 Oct 2004 13:28:00 -0000 [thread overview]
Message-ID: <41747AC2.nailJWG1NGL1K@mindspring.com> (raw)
In-Reply-To: <C863B68032DED14E8EBA9F71EB8FE4C20508B471@azsmsx406>
"Hanson, Jonathan M" <jonathan.m.hanson@intel.com> 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
prev parent reply other threads:[~2004-10-19 2:23 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-18 23:41 Hanson, Jonathan M
2004-10-19 2:23 ` Daniel Jacobowitz
2004-10-19 13:28 ` Michael Chastain [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=41747AC2.nailJWG1NGL1K@mindspring.com \
--to=mec.gnu@mindspring.com \
--cc=gdb@sources.redhat.com \
--cc=jonathan.m.hanson@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox