On 02.11.2015 11:12, Jacek Caban wrote:
Sure. The idea is to pass relative addresses
instead to
call_syscall_func and let it handle that. Calling call_syscall_func
itself may use a constant address if we let it live in user shared data.
Did you try that? That's one of those things that one has to try to see
if it works in practice.
Yes, I also looked at this approach. The difficult part
to get this correct
is to initialize user shared data as early as possible, without any call to
a wrapper function before that. Please note that its not sufficient to wrap
calls from other dlls, even some ntdll-internal calls have to go through the
wrappers (for example when loading a library). Those are implemented in
ntdll usermode on Windows.
Also I believe that using winebuild for that is
the right way.
I already tried it out in practice and partially disagree. As
mentioned above,
its not sufficient to put autogenerated wrappers between the implementation
and the ntdll exports. Exactly the same wrappers have to be used from inside
of the ntdll loader code for example. This means, even if the thunks are
generated somewhere else, we still have to add them to one of the wine header
files. If we do not want to generate thunks for all architectures, we might
even have to add them twice, one time as typedef, and the second time a #define
as fallback for unsupported architectures.
I'm not saying that its impossible to do it this way, but compared to thiscalls,
which could easily be generated by winebuild, a macro is similar good here imho.
If you want to look into the idea to autogenerate thunks, here is one of my
work-in-progress patches (based on Erichs work):
http://ix.io/lLz See attached
patches. On the quick look it seems similar to the one you
mentioned, except it avoids text relocations. The patch is definitely
not finished nor ready for proper review, but it's enough to get things
to build and run. I haven't even tested that with Chromium nor other
apps that need it (well, I haven't tested it at all, really).
Patch 1 is the interesting one. Patch 2 just marks needed functions as
syscalls.
Patch 3 is to show how to address your concerns about going through
thunks from inside ntdll. Those use macros from your patch except their
meaning is reverted. I chose two calls that I know will need to be fixed
for Office. I don't know how much more calls will need to be changed. In
general, we can't avoid such problems: we will either need to explicitly
mark calls that need to go through the thunk or those that don't. I
chose the first variant because it seems cleaner and more in line with
how winebuild works. I do believe that implementing things to work the
other way around is also possible in winebuild.
Cheers,
Jacek