Mirror of the gdb mailing list
 help / color / mirror / Atom feed
* Accessing x86 general-purpose registers
@ 2004-10-18 23:41 Hanson, Jonathan M
  2004-10-19  2:23 ` Daniel Jacobowitz
  2004-10-19 13:28 ` Michael Chastain
  0 siblings, 2 replies; 3+ messages in thread
From: Hanson, Jonathan M @ 2004-10-18 23:41 UTC (permalink / raw)
  To: gdb

	My question really isn't about GDB per se but I was hoping some
of the developers on this list would be able to help with what I'm
trying to do.
	I have written a kernel module that, when triggered by an event,
dumps out the contents of memory and the architectural state of the
system to two files. The problem I'm running into is that the general
purpose registers (EAX, EBX, EIP, etc.) I'm storing are incorrect. To
investigate this problem I've downloaded the source to GDB and I've been
looking at how GDB accomplishes this.
	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?


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Accessing x86 general-purpose registers
  2004-10-18 23:41 Accessing x86 general-purpose registers Hanson, Jonathan M
@ 2004-10-19  2:23 ` Daniel Jacobowitz
  2004-10-19 13:28 ` Michael Chastain
  1 sibling, 0 replies; 3+ messages in thread
From: Daniel Jacobowitz @ 2004-10-19  2:23 UTC (permalink / raw)
  To: Hanson, Jonathan M; +Cc: gdb

On Mon, Oct 18, 2004 at 01:03:42PM -0700, Hanson, Jonathan M wrote:
> 	My question really isn't about GDB per se but I was hoping some
> of the developers on this list would be able to help with what I'm
> trying to do.
> 	I have written a kernel module that, when triggered by an event,
> dumps out the contents of memory and the architectural state of the
> system to two files. The problem I'm running into is that the general
> purpose registers (EAX, EBX, EIP, etc.) I'm storing are incorrect. To
> investigate this problem I've downloaded the source to GDB and I've been
> looking at how GDB accomplishes this.
> 	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?

I am inferring from context that you are talking about Linux.  You may
have better luck on a Linux development list; GDB uses ptrace, and the
kernel takes care of connecting the registers to that.

-- 
Daniel Jacobowitz


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Accessing x86 general-purpose registers
  2004-10-18 23:41 Accessing x86 general-purpose registers Hanson, Jonathan M
  2004-10-19  2:23 ` Daniel Jacobowitz
@ 2004-10-19 13:28 ` Michael Chastain
  1 sibling, 0 replies; 3+ messages in thread
From: Michael Chastain @ 2004-10-19 13:28 UTC (permalink / raw)
  To: jonathan.m.hanson, gdb

"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


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2004-10-19  2:23 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-10-18 23:41 Accessing x86 general-purpose registers Hanson, Jonathan M
2004-10-19  2:23 ` Daniel Jacobowitz
2004-10-19 13:28 ` Michael Chastain

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox