[PATCH 1/3] winebuild: Added support for entry points generated in runtime.

[Jacek Caban]

On 01/21/16 16:58, Jacek Caban wrote:
> On 01/21/16 16:04, Sebastian Lackner wrote:
>> On 21.01.2016 15:43, Jacek Caban wrote:
>>> On 01/19/16 17:06, Alexandre Julliard wrote:
>>>> Jacek Caban <jacek at codeweavers.com> writes:
>>>>
>>>>> All such solutions require changes in both Chrome and Wine, which makes
>>>>> it tricky to decide on a solution. What's your opinion?
>>>> My concern is not just about hooking the system calls, it's what happens
>>>> once they are hooked. Sebastian said that hooks inside the Ldr*
>>>> functions don't work right. I'm worried that supporting this properly
>>>> would require that our internal code paths follow the Windows ones
>>>> closely, which is neither feasible nor desirable.
>>>>
>>>> This could of course also be changed in Chrome so that it could deal
>>>> with the way Wine's ntdll is implemented, but that would probably be
>>>> more intrusive.
>>> It's hard to discuss what Sebastian reports without understanding the
>>> problem. For what I know, his variant of patches exposes way more
>>> hookable calls than it should. It's not a secret that on Windows Nt*
>>> functions will not call any other exported functions. This is an
>>> implementation detail that I don't consider too internal to follow. The
>>> fact that those hooks may be called recursively with Sebastian's patches
>>> makes me think that it's the most likely reason of the problems.
>> Could you please point out where you think my patchset doesn't match
>> Windows behavior / leads to recursive calls which should not occur?
> I looked deeper in your patchset and the one occur that I thought was
> there was my mistake.

Actually no, it was a valid example. Here is a stack that has two syscalls:

NtOpenFile -> FILE_CreateFile -> nt_to_unix_file_name_attr ->
RtlAllocateHeap -> HEAP_FindFreeBlock -> HEAP_CreateSubHeap ->
NtAllocateVirtualMemory

Cheers,
Jacek