It’s not obvious from Intel’s manual how the return address is maintained.
It makes stack back trace much difficult than on x86 or amd64.
Does anyone know if there’s any web link talks about this?
Thanks,
Calvin
Calvin Guan Software Engineer
ATI Technologies Inc. www.ati.com
-----Original Message-----
From: Maxim S. Shatskih [mailto:xxxxx@storagecraft.com]
Sent: Thursday, April 22, 2004 4:28 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Thread IDs
IIRC they are handles in System process handle table.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From: “Michal Vodicka”
> To: “Windows System Software Devs Interest List”
> Sent: Friday, April 23, 2004 12:02 AM
> Subject: [ntdev] Thread IDs
>
>
> > Does anybody know how thread IDs are generated? I’d like to
> know the maximal
> TID I can expect under normal conditions. On XP (SP0, SMP
> kernel) it seems TIDs
> fall to 0 - 0xfff range.
> >
> > Note I need it for debugging purposes only and don’t intend
> to use any
> assumption about TIDs in production code. Also, even
> debugging code won’t crash
> if the assumptions fails. What I need is something reasonable
> which works in
> about 90% of cases under normal conditions.
> >
> > Best regards,
> >
> > Michal Vodicka
> > UPEK, Inc.
> > [xxxxx@upek.com, http:://www.upek.com]
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> > To unsubscribe send a blank email to
> xxxxx@lists.osr.com
> >
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@ati.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
Walk the stack on Itanium systemYou’re asking about calling conventions,
which aren’t architectural, which is why you don’t find them in the Intel
manuals. If you want to know about how it’s done in Windows, I strongly
suggest reading Microsoft’s documentation. As an example, here’s an excerpt
from “debugger.chm,” which is part of the WinDbg package which you probably
have. (Much of the nice formatting has been lost, since I didn’t want to
send this message as HTML.)
Integer Registers
The 128 integer registers are named r0 through r127 and break down as
follows:
r0 - r31 Static general registers
r32 - r127Stacked general registers
Some of the registers have special meaning, most of which are assigned by
convention rather than hardware requirement. (The only one that is a
hardware requirement is r0.)
r0 Reads as zero (writing will AV)
gp Global pointer (r1)
ret0 - ret3Function return values go here (r8 through r11).
sp Stack pointer (r12)
r13 TEB
By convention, registers r4 through r7 are preserved. You also should not
change the TEB pointer.
The gp register points to your global variables. To access a global
variable, you have to indirect OFF the gp register. The gp register is kept
up-to-date when you jump from one DLL to another (by means described later).
The other static registers are scratch.
All integer registers are 64 bits, with a magic NaT bit attached to each
one. NaT stands for “not a thing” and is used by speculative execution to
indicate that the register values are undefined.
The static integer registers do not participate in register stacking. The
behavior of the stacked registers (including their preservation rules) will
be described in Procedure Calls and the Register Stack subsection of this
section.
The return value registers hold function return values and therefore can be
destroyed across a function call. Notice that there are four integer return
value registers at 64 bits each, for a total of 256 bits or 32 bytes of data
that can be returned from a function (twice the size of a GUID).
“Calvin Guan” wrote in message news:xxxxx@ntdev…
It’s not obvious from Intel’s manual how the return address is maintained.
It makes stack back trace much difficult than on x86 or amd64.
Does anyone know if there’s any web link talks about this?
Thanks,
Calvin
-
Calvin Guan Software Engineer
ATI Technologies Inc. www.ati.com
> -----Original Message-----
> From: Maxim S. Shatskih [mailto:xxxxx@storagecraft.com]
> Sent: Thursday, April 22, 2004 4:28 PM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] Thread IDs
>
>
> IIRC they are handles in System process handle table.
>
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
>
> ----- Original Message -----
> From: “Michal Vodicka”
> To: “Windows System Software Devs Interest List”
> Sent: Friday, April 23, 2004 12:02 AM
> Subject: [ntdev] Thread IDs
>
>
> > Does anybody know how thread IDs are generated? I’d like to
> know the maximal
> TID I can expect under normal conditions. On XP (SP0, SMP
> kernel) it seems TIDs
> fall to 0 - 0xfff range.
> >
> > Note I need it for debugging purposes only and don’t intend
> to use any
> assumption about TIDs in production code. Also, even
> debugging code won’t crash
> if the assumptions fails. What I need is something reasonable
> which works in
> about 90% of cases under normal conditions.
> >
> > Best regards,
> >
> > Michal Vodicka
> > UPEK, Inc.
> > [xxxxx@upek.com, http:://www.upek.com]
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> > To unsubscribe send a blank email to
> xxxxx@lists.osr.com
> >
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@ati.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
I don’t know anything about Itanium, so please forgive my ignorance, but
presumably you can figure out where the return address would be by
looking at the documentation for the “return from subroutine” (or
equivalent) instruction. It should tell you where it expects the return
address to be, assuming you’re asking about where in the hardware
registers it would be. If you’re asking about where it might be
preserved for non-leaf functions, such as a stack in memory, that may be
determined by a software convention. You could step into a few function
calls and watch what happens to the return address, if documentation for
the convention is not immediately available.
Chuck
----- Original Message -----
From: “Calvin Guan”
To: “Windows System Software Devs Interest List”
Sent: Friday, April 23, 2004 4:37 AM
Subject: [ntdev] Walk the stack on Itanium system
> It’s not obvious from Intel’s manual how the return address is
maintained.
> It makes stack back trace much difficult than on x86 or amd64.
>
> Does anyone know if there’s any web link talks about this?
>
> Thanks,
> Calvin
> -
> Calvin Guan Software Engineer
> ATI Technologies Inc. www.ati.com
>
> > -----Original Message-----
> > From: Maxim S. Shatskih [mailto:xxxxx@storagecraft.com]
> > Sent: Thursday, April 22, 2004 4:28 PM
> > To: Windows System Software Devs Interest List
> > Subject: Re: [ntdev] Thread IDs
> >
> >
> > IIRC they are handles in System process handle table.
> >
> > Maxim Shatskih, Windows DDK MVP
> > StorageCraft Corporation
> > xxxxx@storagecraft.com
> > http://www.storagecraft.com
> >
> >
> > ----- Original Message -----
> > From: “Michal Vodicka”
> > To: “Windows System Software Devs Interest List”
> > Sent: Friday, April 23, 2004 12:02 AM
> > Subject: [ntdev] Thread IDs
> >
> >
> > > Does anybody know how thread IDs are generated? I’d like to
> > know the maximal
> > TID I can expect under normal conditions. On XP (SP0, SMP
> > kernel) it seems TIDs
> > fall to 0 - 0xfff range.
> > >
> > > Note I need it for debugging purposes only and don’t intend
> > to use any
> > assumption about TIDs in production code. Also, even
> > debugging code won’t crash
> > if the assumptions fails. What I need is something reasonable
> > which works in
> > about 90% of cases under normal conditions.
> > >
> > > Best regards,
> > >
> > > Michal Vodicka
> > > UPEK, Inc.
> > > [xxxxx@upek.com, http:://www.upek.com]
> > >
> > >
> > > —
> > > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> > >
> > > You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> > > To unsubscribe send a blank email to
> > xxxxx@lists.osr.com
> > >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@ati.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@cbatson.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
As for a complete off-topic (not too unusual on this forum) I’d like to
point out that there are several architectures of processors where the
return address is maintained as an indirect register. One that I worked with
is 29k. It has LR0 as the return address. However, LR0 is a register pointed
to by LR1. To find the next LR1, you need to modify GR0 to point to the
current contents of LR0. There are 128 local registers (LR0 to LR127). For
stacks that need more than 128 32-bit words, you’d spill off the remainder
whenever suitable to memory [register stack].
Under normal circumstances (i.e. you haven’t just come out of task switch)
there is no memory corresponding to the LR0 or LR1, so you can’t just go
poking around in memory freely. Of course, you could always store LR0 to
LR127 in memory somewhere, preferrably on the register stack.
I wouldn’t be entirely surprised if Itanium has a similar structure.
–
Mats
-----Original Message-----
From: Chuck Batson [mailto:xxxxx@cbatson.com]
Sent: Friday, April 23, 2004 6:27 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Walk the stack on Itanium system
I don’t know anything about Itanium, so please forgive my
ignorance, but
presumably you can figure out where the return address would be by
looking at the documentation for the “return from subroutine” (or
equivalent) instruction. It should tell you where it expects
the return
address to be, assuming you’re asking about where in the hardware
registers it would be. If you’re asking about where it might be
preserved for non-leaf functions, such as a stack in memory,
that may be
determined by a software convention. You could step into a
few function
calls and watch what happens to the return address, if
documentation for
the convention is not immediately available.
Chuck
----- Original Message -----
From: “Calvin Guan”
> To: “Windows System Software Devs Interest List”
> Sent: Friday, April 23, 2004 4:37 AM
> Subject: [ntdev] Walk the stack on Itanium system
>
>
> > It’s not obvious from Intel’s manual how the return address is
> maintained.
> > It makes stack back trace much difficult than on x86 or amd64.
> >
> > Does anyone know if there’s any web link talks about this?
> >
> > Thanks,
> > Calvin
> > -
> > Calvin Guan Software Engineer
> > ATI Technologies Inc. www.ati.com
> >
> > > -----Original Message-----
> > > From: Maxim S. Shatskih [mailto:xxxxx@storagecraft.com]
> > > Sent: Thursday, April 22, 2004 4:28 PM
> > > To: Windows System Software Devs Interest List
> > > Subject: Re: [ntdev] Thread IDs
> > >
> > >
> > > IIRC they are handles in System process handle table.
> > >
> > > Maxim Shatskih, Windows DDK MVP
> > > StorageCraft Corporation
> > > xxxxx@storagecraft.com
> > > http://www.storagecraft.com
> > >
> > >
> > > ----- Original Message -----
> > > From: “Michal Vodicka”
> > > To: “Windows System Software Devs Interest List”
>
> > > Sent: Friday, April 23, 2004 12:02 AM
> > > Subject: [ntdev] Thread IDs
> > >
> > >
> > > > Does anybody know how thread IDs are generated? I’d like to
> > > know the maximal
> > > TID I can expect under normal conditions. On XP (SP0, SMP
> > > kernel) it seems TIDs
> > > fall to 0 - 0xfff range.
> > > >
> > > > Note I need it for debugging purposes only and don’t intend
> > > to use any
> > > assumption about TIDs in production code. Also, even
> > > debugging code won’t crash
> > > if the assumptions fails. What I need is something reasonable
> > > which works in
> > > about 90% of cases under normal conditions.
> > > >
> > > > Best regards,
> > > >
> > > > Michal Vodicka
> > > > UPEK, Inc.
> > > > [xxxxx@upek.com, http:://www.upek.com]
> > > >
> > > >
> > > > —
> > > > Questions? First check the Kernel Driver FAQ at
> > > http://www.osronline.com/article.cfm?id=256
> > > >
> > > > You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> > > > To unsubscribe send a blank email to
> > > xxxxx@lists.osr.com
> > > >
> > >
> > >
> > > —
> > > Questions? First check the Kernel Driver FAQ at
> > > http://www.osronline.com/article.cfm?id=256
> > >
> > > You are currently subscribed to ntdev as: xxxxx@ati.com
> > > To unsubscribe send a blank email to
> xxxxx@lists.osr.com
> > >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@cbatson.com
> > To unsubscribe send a blank email to
> xxxxx@lists.osr.com
> >
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@3dlabs.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>