KSTK_EIP and KSTK_ESP

KSTK_EIP and KSTK_ESP

[Balbir Singh]

Do we really need these defines, I found that it
is not used anywhere and defined as deadbeef on
some architectures. Does it make sense to remove
these variables from the kernel source?

Balbir


_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com

Re: KSTK_EIP and KSTK_ESP

[David S. Miller]

   From: "Balbir Singh" <balbir_soni@hotmail.com>
   Date: Fri, 08 Feb 2002 12:36:59 -0800

   Do we really need these defines, I found that it
   is not used anywhere and defined as deadbeef on
   some architectures. Does it make sense to remove
   these variables from the kernel source?
   
Perhaps your copy of grep is buggy, check out
fs/proc/array.c which does make use of those macros.

Re: KSTK_EIP and KSTK_ESP

[Balbir Singh]

My fault, I was using lxr.linux.no. I was also confused by
the way it is defined in include/asm-parisc (2.4.17)

#define KSTK_EIP(tsk)   (0xdeadbeef)
#define KSTK_ESP(tsk)   (0xdeadbeef)

Thanks for pointing this out,
Balbir



>From: "David S. Miller" <davem@redhat.com>
>To: balbir_soni@hotmail.com
>CC: linux-kernel@vger.kernel.org, tigran@veritas.com
>Subject: Re: KSTK_EIP and KSTK_ESP
>Date: Fri, 08 Feb 2002 12:55:22 -0800 (PST)
>
>    From: "Balbir Singh" <balbir_soni@hotmail.com>
>    Date: Fri, 08 Feb 2002 12:36:59 -0800
>
>    Do we really need these defines, I found that it
>    is not used anywhere and defined as deadbeef on
>    some architectures. Does it make sense to remove
>    these variables from the kernel source?
>
>Perhaps your copy of grep is buggy, check out
>fs/proc/array.c which does make use of those macros.
>




_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com

Re: KSTK_EIP and KSTK_ESP

[Albert D. Cahalan]

Balbir Singh writes:

> Do we really need these defines, I found that it
> is not used anywhere and defined as deadbeef on
> some architectures. Does it make sense to remove
> these variables from the kernel source?

You should implement these. The names may be x86-specific,
but the purpose is not.

EIP -- user instruction pointer or (eeew!) program counter
ESP -- user stack pointer, as defined by your ABI

KSTK_EIP and KSTK_ESP

[Hanson, Jonathan M]

	I'm trying to figure out the magic that's going on in KSTK_EIP
and KSTK_ESP, which are defined as macros in
include/asm-i386/processor.h for a 2.4 kernel. Here are their
definitions below:

#define KSTK_EIP(tsk) (((unsigned long *)(4096 + (unsigned
long)(tsk)))[1019])
#define KSTK_ESP(tsk) (((unsigned long *)(4096 + (unsigned
long)(tsk)))[1022])

I know that the memory allocated to the process to hold its descriptor
and stack by the kernel is two pages. Both of the above macros appear to
go half-way up the allocated memory and then skip to the offsets of 1019
and 1022, respectively, down the allocated memory.
	Can someone explain the structure of the memory that these two
macros are accessing? Specifically, where do the 1019 and 1022 offsets
come from? Also, what other things are stored at other offsets? Where is
this stack structure defined?
	Thanks you for your help in advance.

Re: KSTK_EIP and KSTK_ESP

[Arjan van de Ven]

On Fri, 2004-11-05 at 16:13 -0700, Hanson, Jonathan M wrote:
> 	Can someone explain the structure of the memory that these two
> macros are accessing? Specifically, where do the 1019 and 1022 offsets

remember the indexes are in multiples of 32 bit, eg the bottom of the
stack, since it's close to the end of the pagesize...

RE: KSTK_EIP and KSTK_ESP

[Hanson, Jonathan M]

>>  Can someone explain the structure of the memory that these two
>> macros are accessing? Specifically, where do the 1019 and 1022
offsets
>> come from? Also, what other things are stored at other offsets? Where
is
>> this stack structure defined?

> if you treat the second (upper) page of the kernel stack as an array
> of dwords and you realize that the initial kernel (ring-0) stack
pointer
> is set at element 1024 then the top elements look like this after a
ring
> transition:
>
> [1023] ring-3 SS
> [1022] ring-3 ESP
> [1021] ring-3 EFLAGS
> [1020] ring-3 CS
> [1019] ring-3 EIP
>
> the ring-0 ESP is stored in the TSS and the thread structure, and it's
> initialized in arch/i386/kernel/process.c:copy_thread().

	Thank you for your reply.
	If I dereference the address in 1022 (the ring 3 ESP address) it
does indeed return the value in EBX. I then thought that I could use
this address to feed to dump_thread() since EBX is the first thing in
the pt_regs structure, but that's not correct in this case because the
other registers are definitely incorrect. Shouldn't the ESP value
pointed to by KSTK_ESP() point to the beginning of the pt_regs structure
for the user space application?

RE: KSTK_EIP and KSTK_ESP

[pageexec]

> Shouldn't the ESP value pointed to by KSTK_ESP() point to the beginning of
> the pt_regs structure for the user space application?

first of all, anything can be on the userland stack at the time the
app issued a syscall. but you don't have to bother with the userland
stack at all, pt_regs is created on the kernel stack, check out the
SAVE_ALL macro (and its uses) in arch/i386/kernel/entry.S .