Open JayFoxRox opened 5 years ago
My patch has landed in https://github.com/llvm-mirror/llvm/commit/7a38c439b6df87ff25c3c67004679ebd4c6ac823 thanks to @thrimbor for tests and upstreaming.
This should be part of LLVM 9.0, which should be released around September 2019.
As result, this should be in Ubuntu 19.10 / Ubuntu 20.04 LTS. There are nightly builds for Ubuntu though, so we can probably upgrade before that, or make it an optional feature.
I'm not sure when MSYS will adapt it, when MSVS adapts it, or how releases work on macOS.
It would be nice if people could test their installation of llvm-dlltool
by following the steps described in this post.
I'm not sure which version of LLVM ships in MSYS2 or on Ubuntu, but if thrimbors patch has propagated, then I'd like to go forward with removing the import-lib binaries from our repository.
You should be able to test your LLVM by compiling a sample with https://github.com/JayFoxRox/nxdk/pull/52 Please delete lib/xboxkrnl/libxboxkrnl.lib before trying this. Also delete your samples main.exe / main.lib / main.obj or any other leftovers from previous compilations.
I did this (after deleting the mentioned files):
$ cd samples/triangle
$ make -B
[...]
$ objdump -x main.exe
[...]
The Import Tables (interpreted .rdata section contents)
vma: Hint Time Forward DLL First
Table Stamp Chain Name Thunk
0001e0ac 0001e0d4 00000000 00000000 0001e2ac 0001e1c0
DLL Name: xboxkrnl.exe
vma: Hint/Ord Member-Name Bound-To
80000036 54 <none>
800000fa 250 <none>
80000001 1 <none>
80000002 2 <none>
80000003 3 <none>
80000018 24 <none>
8000002c 44 <none>
8000002e 46 <none>
8000002f 47 <none>
80000031 49 <none>
80000043 67 <none>
80000045 69 <none>
80000062 98 <none>
80000063 99 <none>
80000064 100 <none>
80000068 104 <none>
8000006b 107 <none>
[...]
You can also use llvm-objdump if you don't have objdump, but the output isn't as meaningful (as it doesn't tell us if the import is by empty name or ordinal - which we care about):
$ llvm-objdump -x main.exe
[...]
The Import Tables:
lookup 0001e0d4 time 00000000 fwd 00000000 name 0001e2ac addr 0001e1c0
DLL Name: xboxkrnl.exe
Hint/Ord Name
54
250
1
2
3
24
44
46
47
49
67
69
98
99
100
104
107
[...]
The built default.xbe should still work.
All of my tests were done on Arch Linux llvm 9.0.0-4 and GNU objdump (GNU Binutils) 2.33.1.
Interestingly, inspecting xboxkrnl.lib seems to imply that the -k
option broke (-k: Kill @n Symbol from export
)? This might be important for DXT support, so please also do this (after building libxboxkrnl.lib with my linked branch):
Edit: -k
option works, it's just not visible in nm
. The linked binaries will have the correct names (Tested on LLVM 9; @dracc also confirmed this behaviour for LLVM 6 on Discord).
I've tested building and running according to the instructions above using llvm-dlltool version 6.0, 7, 8, 9 and 10.
9 and 10 seems to work (as was expected).
Do note that none of these packages creates a symlink for llvm-dlltool
by default in Debian - you have to create one yourself.
All my tests were run on Debian testing with GNU Binutils 2.33.1.
Keep tests from MSYS2 and Ubuntu coming please (which version of LLVM do they use by default?)
Also https://reviews.llvm.org/D68352#1700956 mentions that lld-link is a better option to create an import lib. I had speculated this myself, because earlier I noticed that it supported /DEF:
; also /LIB
to make it behave like lib.exe (which is our actual goal). I'm not sure if it actually respects the /DEF
option in /LIB
mode, because llvm-lib (which should be lib.exe) does not support it (for reasons I don't understand).
Users should be able to modify libxboxkrnl.lib and others. Our makefile should generate these files.
This was originally part of nxdk, but we removed it because the LLVM tools didn't create compatible import libs.
I've now created a patch for llvm-dlltool that makes this possible. I try to get this upstreamed, although I'm not motivated to use their mailing-list.
It's optional for xboxkrnl.lib, because that's considered complete. However, we might want other import libs in the future (I'm working on xbdm.lib for example).
(Edit: This section was added in September 2019)
I'm removing my fork of LLVM; this was the description for my LLVM patch (which has been upstreamed; see comment from May below):
The patch was aimed to fix issues with an import libraries for DXT (dynamically linked debugger extension) but also affects the xboxkrnl import library.