On Thu, 3 Aug 2000, Marcus Meissner wrote:
> > 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.
That's what I was afraid of.
> > 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?
Most likely an abstraction, but it's still kernel threads underneath rather
than a pure userspace solution.
> We do use the hard-and-ugly direct kernel thread way.
How different is it?
> > /* 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.
Are there other alternatives? Tricking it into thinking the misunderstood
frames don't exist at all? Or is the only hope to get the libsafe people
to hack it to work better with Wine? (Normally, I doubt they'd want to
tune it for a particular application, but Wine might be an exception?)
> > 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.
Is there any conceivable way to make the exception-handling stack frames
more comprehensible to gcc, by any chance?
As for libsafe, if it's inherently incompatible, it might be possible to
wrap the wrappers to bypass the intercept code, to let Wine function on a
system normally protected by libsafe... (Ugly hack, though!)
Deven
