Delphi 5 debugger is working!

Vitaliy Margolen wine-devel at kievinfo.com
Tue Aug 23 19:05:25 CDT 2005


As of todays CVS Delphi 5 debugger is fixed.

Well, ok, there are still some bugs. One is a minor bug (Module view reports all
modules as a project executable name), but all exports are there. You can even
try to disassemble them. But here is where the major problems start. Debugger
segfaults on that. This is because NtQueryVirtualMemory and
NtProtectVirtualMemory currently don't work on other processes.

I have modified those functions to return STATUS_SUCCESS instead. This allows to
access ntdll, kernel32 and possibly any other modules that have the same base
address for application and debugger. You might need prelink installed to
relocate ntdll and kernel32 to 0x7bxxxxxx addresses. This makes their base
addresses the same for all wine apps.

Unfortunately fixing NtQueryVirtualMemory, NtProtectVirtualMemory and others
is not that simple. Basically there are no way to do it from other processes.
Ok, NtQueryVirtualMemory could be implemented some-what easily using
NtReadVirtualMemory and possibly one more server call. But for others I see only
three ways to implement them:
1. Adding worker thread to each process. This way we can ask it to perform
   requested operation for us. But, there is a catch - this will complicate lots
   of things. Besides, messing with processes is not a good thing(tm). It will
   brake some apps, that don't expect to see more then one thread. Or if we'll
   try to hide a worker thread, it will make things even worse.
2. Using signal(s). Unfortunately this is not as simple to do ether. From what I
   been told, this will require non trivial synchronization, that still doesn't
   guarantee deadlocks.
3. Infamous wine kernel module. Some how I don't think that kernel guys will go
   for this type of functionality. Even for debugging proposes, it still poses
   considerable security risk allowing one process manipulate other process'
   memory. So it will have to be a wine only module, which means we'll have to
   maintain in against all supported kernel versions and require kernel
   development environment.

Any other solutions that I have forgotten/haven't even thought of?

-- 
Best regards,
 Vitaliy





More information about the wine-devel mailing list