Jacek Caban : dbghelp: Use Windows API to map macho files.

[Jacek Caban]

Hi Ken,

On 23.03.2020 05:55, Ken Thomases wrote:
> I assume that this and your other recent dbghelp changes are to get it building as PE, right?


Long story short, yes, you're right. This particular commit was a port 
of the similar change for ELF files. The direct motivation for ELF file 
change was my recent work on supporting GNU debug links with PE files. 
We already had its implementation tied to ELF handling. There is no 
reason such links can't support different formats, so PE file can point 
to ELF file containing its debug info or ELF can point to a PE file with 
debug info. To get that right, I had to abstract file format handling 
some more and do runtime format check. While designing it, a question 
about future move to PE was a deciding factor on the solution (using 
HANDLE to check file magic and pass it down to proper backend).


When changing backend interface, the question about future PE move 
popped up so many times that once I changed mapping to use Win32 API, as 
an experiment, I tried hacking dbghelp PE build to be able to handle ELF 
files. I was positively supersized how easy it was to get it working on 
Linux (well, at least 32-bit), so I decided that it's worth taking a 
look. Of course, proper solutions proved to be much more tricky, but 
even PE build aside, those changes are a nice clean up IMHO. Right now, 
in my WIP tree, I have PE build working both for debugging 32-bit Linux 
and macOS. It still needs finishing and clean up.


BTW, there is no dbghelp design reason we wouldn't support debug links 
to/from macho files. It's just that I don't think that toolchain 
provides a sane way to do that. But there is no reason we can't support 
PE -> ELF links when running on macOS. With enough abstraction, we just 
need a bunch of ELF structs available on platforms that don't provide 
them natively (like mingw, macOS).


> That's a little unfortunate since it should really use libunwind on macOS (and maybe Android?).  I've got a partial implementation of that lying around somewhere.  I guess we'll eventually have some mechanism to have a DLL partially implemented with host libraries and that will have to do. :-/


We can use PE build of libunwind (or whatever other library we need). 
Ideally, it would support multiple target platforms, so that all 
platforms would benefit. More broadly speaking, what we need for dbghelp 
is not limited to our use case. Multi-platform debuggers with remote 
capabilities (like gdb or lldb) also need to be able to handle the same 
problems without depending on host platforms to do the job. It might be 
interesting to see how they handle it.


Actually, I was planning to ask you about a few implementation details, 
so let me use the chance here. I still have a few native calls in macho 
backend that I need to handle properly (I just commented them out in my 
PE builds). Please let me know what you think:


https://source.winehq.org/git/wine.git/blob/3ddf3a720f2a342141550c973f10854b573d80ed:/dlls/dbghelp/macho_module.c#l1218

I guess we will need to expose lookup by GUID from mount manager via ioctl.


https://source.winehq.org/git/wine.git/blob/3ddf3a720f2a342141550c973f10854b573d80ed:/dlls/dbghelp/macho_module.c#l1413

Do we still need it? Both ELF and 64-bit mac is fine depending entirely 
on PEB. I was thinking about removing it.


https://source.winehq.org/git/wine.git/blob/3ddf3a720f2a342141550c973f10854b573d80ed:/dlls/dbghelp/macho_module.c#l1868

Similar to above, we should be able to get that from PEB. Also, the "It 
will almost always be the same." does not really hold when debugging wow32.


Thanks,

Jacek