I assume that this and your other recent dbghelp changes are to get it building as PE, right?
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. :-/
-Ken
On Mar 19, 2020, at 4:27 PM, Alexandre Julliard julliard@winehq.org wrote:
Module: wine Branch: master Commit: ebf57f01f4890b726a0af702ab7751258f5ab03d URL: https://source.winehq.org/git/wine.git/?a=commit;h=ebf57f01f4890b726a0af702a...
Author: Jacek Caban jacek@codeweavers.com Date: Thu Mar 19 18:35:54 2020 +0100
dbghelp: Use Windows API to map macho files.
Signed-off-by: Jacek Caban jacek@codeweavers.com Signed-off-by: Alexandre Julliard julliard@winehq.org
dlls/dbghelp/image_private.h | 2 +- dlls/dbghelp/macho_module.c | 136 +++++++++++++++++++------------------------ 2 files changed, 61 insertions(+), 77 deletions(-)
Diff: https://source.winehq.org/git/wine.git/?a=commitdiff;h=ebf57f01f4890b726a0af...
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/3ddf3a720f2a342141550c973f10854b...
I guess we will need to expose lookup by GUID from mount manager via ioctl.
https://source.winehq.org/git/wine.git/blob/3ddf3a720f2a342141550c973f10854b...
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/3ddf3a720f2a342141550c973f10854b...
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
-
Jacek Caban -
Ken Thomases