I have a rather large program that I have been happily using jwasm on without problem. Then, I had some weirdness happen I couldn't explain, so I thought I'd drop back to masm. After spending an hour putting in superfluous syntax that masm needs and jwasm doesn't I finally got it to assemble, but now I am getting linker error "LNK1190: invalid fixup found, type 0x0001"
How does one find what is causing this type of error?
Jim,
Linker option /verbose could help to chase it down.
A good thought, but it made no difference. Link didn't get far enough to put out any messages at all other than the one above.
here is the total output-
F:\WinAsm\Progs\Sol>F:\masm32\BIN\Link /SUBSYSTEM:WINDOWS /RELEASE /VERBOSE /MAP
/MAPINFO:FIXUPS "/LIBPATH:F:\masm32\LIB" "Sol.obj" "Sol.res" "/OUT:Sol.exe"
Microsoft (R) Incremental Linker Version 5.12.8078
Copyright (C) Microsoft Corp 1992-1998. All rights reserved.
Start Pass1
Sol.obj : fatal error LNK1190: invalid fixup found, type 0x0001
F:\WinAsm\Progs\Sol>pause
Press any key to continue . . .
do you have any 16-bit references in a 32-bit section ?
32-bit references in a 16-bit segment ?
and so on
another possibility is an incompatible OBJ file - try a different linker version maybe ?
or see if the assembler and linker are from the same era, at least :P
I certainly didn't intend to do any 16bit references, but masm could have mistook something for one. Even if another linker worked, it wouldn't find the problem. I'm sure it's something I took advantage of that jwasm can do much better than masm, and now I'm paying the price. I'll start putting overides on everything until I find it. And I'm not at all sure that it will solve my original problem, I thought switching to masm would be a quickie test. Guess not.
Quote from: dedndave on April 15, 2014, 04:50:28 AM
or see if the assembler and linker are from the same era, at least :P
That's probably the issue here - incompatibility between ML and LINK.
Try link /incremental:no ...
As to JWasm: I love it, it's good and much faster than Masm, but when I build my libraries, I do it first with JWasm to see if it works, then with ML 6.15 for the release version.
If you use PEview to look into the OBJ file, and Type 0x0001 is referring to IMAGE_REL_I386_DIR16 (usually should be 0x0006 IMAGE_REL_I386_DIR32), then you should be able to see at least one of these in the IMAGE_RELOCATION records. The symbol name and RVA are also displayed which should help narrow things down.
Does link v5.12 use COFF? I thought it was the 16-bit linker.
Finally found it.
I use the $ notation a lot to get addresses, e.g.
.data
xtest = $
db "This is a test",0
and then just use xtest wherever I need an actual address, rather than typing "dword ptr" or "offset" all over the place. Jwasm always knows this is a four byte address. Masm, not so much, some of the time it screws up, and the above error is the result.
Little surprises ;-)
Especially ML 6.15 is a pig. But try this, works with 6.14 ... 10 and JWasm:
include \masm32\include\masm32rt.inc
.data
curadd=$
db "This is a test",0
.code
xtest CATSTR <dword ptr offset >, <curadd>
% echo xtest
start: print xtest
exit
end start
It also worked for 90% of the instances in masm, it was just a few where it got confused. Everything good now. Just had to test for opattr 25h in some macros and handle appropriately :)
i believe the $ bug is documented
i try to avoid $ :P