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
Best Regards, Sebastian