Hi
I'm moving my stuff to USAM and I tried to build my library (ObjMem32.lib) with USAM32. It builds Ok so far, but when I try to use its procs I get the following error message when linking:
QuoteINK : LNK6004: Demo01A.exe not found or not built by the last incremental link; performing full link
ObjMem32.lib(DbgOutTextA.obj) : fatal error LNK1190: invalid fixup found, type 0x0001
Depending on the used proc it fails on different obj modules. Any idea what is going wrong?
I use the following code to build
Quote\UASM32.EXE /nologo /c /coff \Code\ObjMem32\386\*.asm
\LINK.EXE -lib *.obj /out:\Code\ObjMem32\ObjMem32.lib /NOLOGO
Biterider
This works for me. What exactly is the problem?include \masm32\include\masm32rt.inc
includelib \Masm32\ObjMem32.lib
.code
start:
BStrAlloc PROTO :DWORD
invoke BStrAlloc, 1000
inkey hex$(eax)
exit
end start
Hi JJ
I uploaded to the first post both libs.
The first differense is the size. The ML version is a bit bigger than the UASM version. Using the first one I can use all library procs as usual. Using the last one, I got the fixup error.
Biterider
I get no errors for both. Is there a specific function that throws the error?
Hi
I found one that can be reproduced with the following code
include \masm32\include\masm32rt.inc
includelib \Masm32\lib\ObjMem32.lib
externdef pFirstObject:DWORD ;Exports pFirstObject symbol
.data
pFirstObject DWORD 0
.code
start:
GetObjectTemplate PROTO :DWORD
invoke GetObjectTemplate, 1
ret
end startCompiling the asm file with ML or UASM make no difference.
[size=78%]This is the output message[/size]QuoteD:\Masm32\Bin\UASM32.EXE /Zd /Zi /c /coff /nologo /I"D:\Masm32\Include" "Demo01A.asm"
***********
ASCII build
***********
Demo01A.asm: 14 lines, 2 passes, 108 ms, 0 warnings, 0 errors
D:\Masm32\Bin\LINK.EXE /SUBSYSTEM:WINDOWS /DEBUG /DEBUGTYPE:CV /VERSION:4.0 /LIBPATH:"D:\Masm32\Lib" /OUT:"Demo01A.exe" "Demo01A.obj"
Microsoft (R) Incremental Linker Version 5.12.8078
Copyright (C) Microsoft Corp 1992-1998. All rights reserved.
ObjMem32.lib(GetObjectTemplate.obj) : fatal error LNK1190: invalid fixup found, type 0x0001
Make error(s) occured.
Total compile time 297 ms
Biterider
Hi
Playing with the library code, I removed the line containing "pFirstObject" and all externdef. Now the code obviously doesn't work, but it compiles with USAM without errors.
It seems to me, that externdef isn't working the same way ML does and the linker can't find the symbols to link the modules containing them.
Regards, Biterider
Hi Biterider :biggrin:
At the moment I am preoccupied with macros and did not have time to see what is going on with your code
Johnsa was absent for few days, he is probably to busy with his work, hopefully he will be able to check it today
I'll finish soon with macros, than if he does not have time, I'll see what I can do about it.
Hi Habran
Thank you for your replay.
Since I have a workaround compiling the lib with ML and using UASM for the rest, it isn't a prio 1 for me.
Biterider
On my machine the code builds fine with externdef pFirstObject:DWORD, but at runtime you get surprises:
GetObjectTemplate:
... UAsm:
0040112B ³> 67:8B16 0000 mov edx, [small 0]
00401130 ³. EB 18 jmp short 0040114A
... ML:
0040112B ³> 8B15 00204000 mov edx, [402000]
00401131 ³. EB 18 jmp short 0040114B
Hi JJ
Thanks for looking into that!
What are you showing us? mov edx, ...
Maybe there is a difference on the used linker. What are you using? I use the one supplied with the MASM32 installation "Microsoft (R) Incremental Linker Version 5.12.8078"
Biterider
Quote from: Biterider on October 09, 2017, 09:06:05 PMWhat are you showing us? mov edx, ...
int 3
invoke GetObjectTemplate, 1 ; 401120
...
00401120 Ú$ 8B4424 04 mov eax, [esp+4] ; Demo01A.00401120(guessed Arg1)
00401124 ³. 85C0 test eax, eax
00401126 ³. 75 03 jnz short 0040112B
00401128 ³. C2 0400 retn 4
0040112B ³> 67:8B16 0000 mov edx, [small 0] ; <<<<<<<<< should be mov edx, [402000]
00401130 ³. EB 18 jmp short 0040114ABtw I get the invalid fixup with the M$ linkers but not with polink. With polink, it builds but:
POLINK: warning: Unknown relocation type (1) for symbol '_pFirstObject'; ignored.And it crashes, see above 8)
Hi,
Can you try assembling the source files individually and also with UASM64 ?
\UASM32.EXE /nologo /c /coff \Code\ObjMem32\386\*.asm
\LINK.EXE -lib *.obj /out:\Code\ObjMem32\ObjMem32.lib /NOLOGO
For your library, just to try and help narrow it down to either UASM32 specifically or the fact that it's running all the files in one session.
If the case is repeatable after that I'll need to be able to try assemble that LIB my side and see where/why the fixup data is being written out as type 1.
Cheers
John
Hi John
I generated all obj files individually calling UASM64 for each file and the build the lib using Link.exe.
The result didn't change. Still "ObjMem32.lib(GetObjectTemplate.obj) : fatal error LNK1190: invalid fixup found, type 0x0001".
How can I help?
Biterider
We need to create an example source for a lib with a similar extern that generates the same type of fixup to trace where/why that happens.
Ideally we need to see what fixup record type is created when ML is used and when UASM is used (seems to be 1) and what it should be.
Would you be able to make a template lib .asm source that exhibits the same issue (without all your dependencies) ?
Hi John
I build a lib with only 1 procedure (GetObjectTemplate) and the problem still persits.
In the attachment is the complete test case. You will find 2 batch files to build the lib and the exe files.
Biterider
Perfect thanks :)
That'll help me track it down!
Quote from: Biterider on October 10, 2017, 02:47:56 AM
Hi John
I build a lib with only 1 procedure (GetObjectTemplate) and the problem still persits.
In the attachment is the complete test case. You will find 2 batch files to build the lib and the exe files.
Biterider
If it helps in any way, I have built the same LIB with just 1 procedure (GetObjectTemplate) but without the 2 upper lines which are not needed for the case (except to equate POINTER to dword)
% include @Environ(OA32_PATH)\\Code\\OA32_Setup.inc
% include &ObjMemPath&ObjMem32.cop
and it works.
Thanks aw27
Confirmed. I'll see what causes the issue in those files.
Biterider
Hi
Thanks to aw27's hint I found the problem. I reduced the sequence of commands/options/etc. from those files to the following code:
POINTER typedef DWORD ;Anonymous pointer
option casemap:none ;Case sensible
option dotname ;Enable dot names
.686p ;Use 686 protected mode
.xmm ;Enable xmm instructions
.model flat, stdcall ;Memory model = flat, use StdCall as default calling convention
NULL equ 0
ALIGN_CODE = 8
.code
externdef pFirstObject:POINTER
OPTION PROLOGUE:NONE
OPTION EPILOGUE:NONE
align ALIGN_CODE
GetObjectTemplate proc dObjectID:DWORD
...
GetObjectTemplate endp
OPTION PROLOGUE:PrologueDef
OPTION EPILOGUE:EpilogueDef
end
Now, if you move the .686p directive to the first line, all is smooth again. The problem is the POINTER typedef.
it seems that the .686p directive in UASM erases all previous definitions while ML remembers them!
Biterider
UASM also does not accept .xmm before the CPU model - if you do and use a xmm instruction it will give an error. MASM does allow. May be this could be fixed.
Well that's really useful :) I will see what I can do to keep any of those arrangements working , at least it hopefully means I don't have to dig through the hideous coff output code to find the fixup :)
Update:
[url]www.terraspace.co.uk/uasm242.zip
1) Prevent .686p (and others) from resetting ext flag bits, so it shouldn't reset .mmx / .xmm anymore.
2) invalid fixup bug found.. when the typedef is evaluated prior to .686p the default memory sizing is assumed to be 16bit, so the relocation/fixup written to the obj file is for 16bit, not 32bit+ COFF. It now assumes 32bit or 64bit depending on the output settings.
Thank you!
Biterider
:t
Very funny!!
The problem still is alive... but is not so dificult to move some lines :biggrin:
Here the thing was externdef previous to model directives.