Bottom of stack on wince
Vincent Richomme
forumer at smartmobili.com
Fri Jul 18 04:20:57 PDT 2008
David,
about the bottom of the stack, here is a "trick" and it's really need
to be called like that because to get it I am accessing kernel data :
extern "C" BOOL SetKMode(BOOL bFlag);
#define PUserKData ((LPBYTE)0xFFFFC800)
int WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPWSTR
lpCmdLine, int nCmdShow)
{
BOOL bKmode = SetKMode(TRUE); //allow us to go into kernel
DWORD dwStackBase = *(DWORD*)(*((DWORD*)(PUserKData + 0x094)) +
0x1C);
SetKMode(bKmode); return 0;
}
Some explanations below :
Actually on all arm plateforms kernel is loaded at 0xFFFFC800 address and
typedef struct ARM_HIGH {
...
char kStack[0x800]; // 0xFFFFC000: kernel stack
struct KDataStruct kdata; // 0xFFFFC800: kernel data page
} ARM_HIGH;
As you can see kernel is the following struct and at 0x094 offset there
is a field called pCurThd representing a PTHREAD :
struct KDataStruct {
LPDWORD lpvTls; /* 0x000 Current thread local storage
pointer */
HANDLE ahSys[NUM_SYS_HANDLES]; /* 0x004 If this moves, change
kapi.h */
char bResched; /* 0x084 reschedule flag */
char cNest; /* 0x085 kernel exception nesting */
char bPowerOff; /* 0x086 TRUE during "power off" processing */
char bProfileOn; /* 0x087 TRUE if profiling enabled */
ulong unused; /* 0x088 unused */
ulong rsvd2; /* 0x08c was DiffMSec */
PPROCESS pCurPrc; /* 0x090 ptr to current PROCESS struct */
PTHREAD pCurThd; /* 0x094 ptr to current THREAD struct */
DWORD dwKCRes; /* 0x098 */
ulong handleBase; /* 0x09c handle table base address */
PSECTION aSections[64]; /* 0x0a0 section table for virutal memory */
LPEVENT alpeIntrEvents[SYSINTR_MAX_DEVICES];/* 0x1a0 */
ulong pAPIReturn; /* 0x2a0 direct API return address for
kernel mode */
uchar *pMap; /* 0x2a4 ptr to MemoryMap array */
DWORD dwInDebugger; /* 0x2a8 !0 when in debugger */
PTHREAD pCurFPUOwner; /* 0x2ac current FPU owner */
PPROCESS pCpuASIDPrc; /* 0x2b0 current ASID proc */
long nMemForPT; /* 0x2b4 - Memory used for PageTables */
DWORD aPend1; /* 0x2b8 - low (int 0-31) dword of
interrupts pending (must be 8-byte aligned) */
DWORD aPend2; /* 0x2bc - high (int 32-63) dword of
interrupts pending */
long alPad[16]; /* 0x2c0 - padding */
DWORD aInfo[32]; /* 0x300 - misc. kernel info */
/* 0x380 - interlocked api code */
/* 0x400 - end */
}; /* KDataStruct */
And finally PTHREAD with at offset 0x1C bottom of stack
struct Thread {
... //
DWORD dwOrigBase; /* 1C: Original stack base */
DWORD dwOrigStkSize; /* 20: Size of the original thread stack */
LPDWORD tlsPtr; /* 24: tls pointer */
DWORD dwWakeupTime; /* 28: sleep count, also pending sleepcnt
}; /* Thread */
David Friedman a écrit :
> Vincent Richomme wrote:
>> Yes that what I did but I wasn't sure.
>> Now here is the remarks I have :
>>
>> 1) in std.c.windows.windows windows functions are declared in their
>> ANSI and UNICODE version but in windows CE only Unicode version
>> exist(except a few exceptions) .
>>
>> My question is should I declare a std.c.windows.windowsce where I
>> could declare only Unicode version and specific functions or should I
>> modify std.c.windows.windows and add some global precompilation
>> variable, for instance UnderCE and Unicode :
>>
>> version(Unicode)
>> {
>> export
>> {
>> BOOL CreateDirectoryW(LPCWSTR lpPathName, LPSECURITY_ATTRIBUTES
>> lpSecurityAttributes);
>> }
>> }
>> else
>> {
>> export
>> {
>> BOOL CreateDirectoryA(LPCSTR lpPathName,
>> LPSECURITY_ATTRIBUTES
>> lpSecurityAttributes);
>> }
>> }
>>
>
> The C header included with the wince-mingw32 package defines both the A
> and W versions, so I do not see the need to do this.
>
>> and then would it be possible to keep the same logic as windows , I
>> mean to be able to use short name (without A or W) in function of
>> encoding.
>>
>>
>>
>> version(Unicode)
>> {
>> alias CreateDirectoryW CreateDirectory
>> ..
>> .
>> }
>> else
>> {
>> alias CreateDirectoryA CreateDirectory
>> }
>>
>>
>
> You could do this. Actually, you may want to bring this up in the main
> newgroup because it applies to the desktop Windows API too.
>
>
>> 2) In std.thread.d and in gc/win32, the function
>> os_query_stackBottom() is implemented using x86 assembler and is not
>> portable to other architecture.
>> By the way why is important to know the "bottom" of stack for the
>> thread ? Is it a hack specific to windows and if I tell you how to get
>> bottom of stack on windows CE will it work ?
>>
>>
>
> The garbage collector needs to know how far back to scan from the top of
> the main stack.
>
> If there is no trick to get it under WinCE, you can adapt the guessing
> code from gc.gcgcc and dgccmain2.d
>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> David Friedman a écrit :
>>> Stagiaire Baptiste et Sandrine wrote:
>>>> Hi,
>>>>
>>>> I'm working on a D crosscompiler targetting arm cellphone running
>>>> wince and I get some trouble with the compilation of the phobos
>>>> library. It cannot find
>>>> the module gcc.config.fpcls.
>>>>
>>>> In the configure script of phobos it appears that for some target
>>>> the variable
>>>> d_use_ieee_fpsb is set. What does fpsb stand for and can we add arm
>>>> on the list
>>>> of supported cpu ?
>>>>
>>>>
>>>
>>>
>>> In the phobos configure.in script, look for this section:
>>>
>>> case "$target_cpu" in
>>> i*86|powerpc*|ppc*|x86_64 ) d_use_ieee_fpsb=1 ;;
>>> *) d_use_ieee_fpsb=0 ;;
>>> esac
>>>
>>>
>>> Change the second line to this:
>>>
>>> i*86|powerpc*|ppc*|x86_64|arm* ) d_use_ieee_fpsb=1 ;;
>>>
>>> If you don't have autoconf, you can directly edit "configure".
>>>
>>> "fpsb" stands for "fpclass()/signbit()"
>>>
>>> David
More information about the D.gnu
mailing list