[MPlayer-dev-eng] [PATCH] Windows DLL support for OS X/Intel (cleaned version)

Stephane LAPIE darksoul at darkbsd.org
Wed Jul 26 17:43:01 CEST 2006


On Wed, Jul 26, 2006 at 05:01:12PM +0300 Valtteri Vuorikoski, Valtteri Vuorikoski <vuori at sci.fi> wrote:
> Stephane Lapie <darksoul at darkbsd.org> writes:
> 
> > I was wondering (as I posted on the Bugzilla) whether this would completely
> > solve the issue. Wouldn't another function call to a lib provided by Apple
> > from the Win32 compatibility functions, require an aligned ESP register and
> > then crash with a SIGILL again ?
> 
> What do you mean by "another function call"? When I was debugging this
> issue, the problem appeared to be with the lazy binding of functions
> from shared libraries (crash inside dylib1.o). With lazy binding
> disabled, this particular problem disappears. Whether other problems
> might appear with DLLs other than the ones I've tested, I don't know.

This is what I was pointing out. :/

> > Is it really proper to ask the user to do this ? Usually (but that's just my
> > opinion there) a program's behaviour should not change that much because of
> > an environment variable. Then again, yes, it's the cleanest way yet to get the
> > job done properly.
> 
> Well, there's the MH_BINDATLOAD header flag which has the same effect
> but is currently apparently ignored by dyld. Maybe Apple will fix that
> some day. One alternative not requiring much code but being rather
> evil I thought of would be to do some symbol-table hackery to
> intercept calls to dylib1.o functions and set up a nice and clean
> environment for the dynamic linker when it's invoked. But I don't
> really know whether this is worth the trouble and hackiness.

I was wondering if one could not define another call convention system and
use it with the win32 compatibility functions. So that on Darwin environment,
these functions would already call the stack cleaner and place function
arguments accordingly. Basically if these files were assembly level, it would
just be a matter of adding the cleaner prefix and suffix before and after the
actual function code. Any gcc guru here ? :/ If possible, this would guarantee
for a much cleaner way of writing the stack cleaning patch I submitted on the
bugzilla.
-- 
Stephane LAPIE, EPITA SRS, Promo 2005
"Even when they have digital readouts, I can't understand them."
--MegaTokyo



More information about the MPlayer-dev-eng mailing list