> > OK, in assembler you need to have special PIC code, as I'm my
> > attempt to an implementation in the most recent mail.
>
> Yes, what I meant is that I did not know at all how to add the PIC
> code so that the linker would do its job. In the elf.c code, the
> linker already did its job, so you already got the address of the
> function.
Hmm, reminds me. Perhaps the problem with the patch is because ...
> > Try the patch in my most recent mail.
>
> I applied it and Wine cannot seem to load libopengl32.so anymore. I
> will try to investigate a bit more. Will send a mail as soon as I find
> out why it fails.
... the "\tcall " #cdecl_name "\n" should be
"\tcall " #cdecl_name "@PLT\n"
when in PIC mode.
This is the only thing I can think of the would prevent loading.
> > My patch (the latest one) is designed for a worst case
> scenario where
> > 1. There might be calls from multiple thread
> > 2. There might be a reentrancy in the same thread.
> >
> > I'm not sure 2 is even possible for OpenGL functions.
> > Are there OpenGL functions that takes callbacks?
> > And if so are these callbacks are allowed to call
> > OpenGL functions. If not the thunking might be done
> > faster.
>
> Nope, they are not callbacks as far as I know in OpenGL, at least none
> that I know of (maybe some extension do, but that would seem a bit far
> fetched for a 'low level' API).
OK, but note that the function that set the callback and the one
the calls it need not be the same.
So _theoretically_ in some implementation an extension function
might set a callback and a normal function might call it. Crash!!!
But note that it is possible to have some functions as reentrant
and some as not, if only we can be certain that it can't happend
for some function.
> Anyway, if you could provide me the same patch but without 1. and
> 2. and without the calls to the X11 crit. sect., I would be very happy
> to do some benchmark with them :-))
Sure, but I do not have time until Saturday or Sunday.
But first priority is making it work at all.
