> > Yes but libsafe needs to walk up the stack to locate the buffer, and
> > there is no guarantee that the Windows app uses the stack layout that
> > libsafe expects. Besides we are using multiple threads and stacks and
> > I don't know if libsafe can cope with this at all.
>
> Is it feasible for Wine to use compatible stack layouts (this would help
> gdb also), or is this impossible due to the Windows API?
This is impossible I am afraid. Win32 apps can access the stack layout
like they want. They also have their own exception mechanisms for
stack walking.
> As for threads, I haven't seen libsafe kill either Netscape 4.72 (which
> uses user-space threads) or Mozilla (which uses kernel threads), so I'd
> guess it can handle it.
Does Mozilla really use direct kernel threads or the LinuxThreads/pthread
style abstraction?
We do use the hard-and-ugly direct kernel thread way.
> /* Given an address 'addr' returns 0 iff the address does not point to
> * a stack variable. Otherwise, it returns a positive number
> * indicating the number of bytes (distance) between the 'addr' and
> * the frame pointer it resides in. Note: stack grows down, and
> * arrays/structures grow up.
> */
While the ebp/frame walking code will work, the above does not apply.
We have data and stack areas scattered through the address space, data
might be above or below the current thread stack, so this function
at least will not work.
It might get a bit addition to understand Win32 stackframes. However,
we have yet another stack weirdness for calling large-stack X11 functions.
> I don't know if this helps you at all, but it would be nice if gdb, libsafe
> and other Unix programs depending on stack frames could work properly...
A tad bit difficult I am afraid ;)
To work around... Hmm:
- Allocate Stackspace by going down from the highest most memory address.
(Implemented MEM_TOP_DOWN for instance.)
- Add hacks to libsafe to understand WINE stack specialities.
Ciao, Marcus
