I read about polink and found this (http://masm32.com/board/index.php?topic=1850.msg23403#msg23403). Are there still problems with debug info and polink, or has this been fixed with later versions?
Is polink a real alternative to MS´s link, or are there known restrictions or problems?
Thanks
JK
Polink works fine, in 64 bit it produces slightly smaller exe files. It is usually very up to date and its well written and very reliable.
From running own tests i can confirm, that polink indeed works like a charm linking 32 and 64 bit executables.
But when it comes to debugging polink´s latest version (9) doesn´t suppport codeview debug information any more. It now uses a different way of supplying debug information suited to Pelle´s IDE. I couldn´t get symbolic debugging to work with e.g. x96dbg - using MS´s link i could.
The nice things is, polink is redistrtibutable, the downside is, you cannot have symbols when debugging (at least i couldn´t get it to work)
The nice thing with MS´s link is, you can have symbols when debugging, the downside here is, it is not redistrtibutable, you must "steal" it from a VS or SDK installation.
JK
Hi JK,
Major changes between 8.00 and 9.00 :
QuoteLinker:
Added support for Pelles C Debug Info, dropped support for Microsoft CodeView info.
http://www.smorgasbordet.com/pellesc/changes_800_900.htm
JK,
> you must "steal" it from a VS or SDK installation.
You don't have to worry, its a legal download. Redistribution is the problem.
I know, that´s why i used quotes.
Quote from: JK on May 25, 2020, 01:21:09 AMBut when it comes to debugging polink´s latest version (9) doesn´t suppport codeview debug information
There is a simple solution: use version 8 :cool:
polink.exe version 8 codeview support is only for 32-bit
Hi gentlemen
I"ve got the polink crash on my input files
I'm using polink.exe version 8.0.2.0 (packaged into masm64 distributive)
Whom should I report the crash details?
2) is it the latest version? if no, please hint me where could I get the latest (and hopefully robust) one
thanks in advance!
Current version is 10 11
Pelles C download link
http://www.smorgasbordet.com/pellesc/
Hi greenozon,
Could post here your project causing the crash of the linker?
Thanks for answers,
I've got the last release of Pelles C (ver 11.0)
and I'd like to test out the polink from that edition
I"ll post my findings tomorrow
Am I right supposing that one could just replace over po**.exe/dll from that installation over into masm64/bin64?
Hello,
Quote
Am I right supposing that one could just replace over po**.exe/dll from that installation over into masm64/bin64?
Yes, you can replace.
as promised,
attached a demo project
to run it:
assemble1-exe.bat test2
and observe the crash of polink, eg:
...
Assembling: test2.asm
CRT: unhandled exception (main) -- terminating
also you'll find the crash dumps generated be WerFault tool in crash dir
eg if you load it into VS: https://prnt.sc/sFGvEP-00uXl
Interesting fact! if you use the MS link.exe it'll also crash with CPU registers dumped out to screen...
2) I"m going to test today the latest po* binaries from Pelles C v11
I cant run it since its 64 bit, but I do see a glaring error. Right after the call to ShowWindow, there is a call to Exit Process.
I see no message loop in the code at all. Meaning no messages will be processed.
If you are successful in assembling and linking this, it will simply exit after creating the window.
Also, Why 30,000 icons in the resource file all pointing to the only icon???
Your Code:
START proc
LOCAL wc :WNDCLASSEX
rcall GetModuleHandle, 0
MOV WCINST,RAX
MOV HINST,RAX
mov WCICON, rv(LoadIcon,HINST, 10)
invoke GetLastError
mov HCURS, rv(LoadCursor,0,IDC_NO)
mov HBGND, rv(GetStockObject, WHITE_BRUSH)
mov wc.cbSize, SIZEOF WNDCLASSEX
mov wc.style, CS_HREDRAW or CS_VREDRAW or CS_DBLCLKS or CS_OWNDC
mov wc.lpfnWndProc, ptr$(WndProc)
mov wc.cbClsExtra, 0
mov wc.cbWndExtra, 0
mrm wc.hInstance, WCINST
mrm wc.hIcon, WCICON
mrm wc.hCursor, HCURS
mrm wc.hbrBackground, HBGND
mov wc.lpszMenuName, 0
mov wc.lpszClassName, ptr$(CLSNAME)
mrm wc.hIconSm, WCICON
invoke RegisterClassEx, ADDR wc
invoke GetLastError
invoke CreateWindowEx,0, ADDR CLSNAME, ADDR WNDNAME, \
WS_OVERLAPPEDWINDOW or WS_VISIBLE, \
CW_USEDEFAULT,CW_USEDEFAULT,200,100,0,0,HINST,0
MOV HWND1,RAX ; Save handle
invoke GetLastError
invoke ShowWindow,EAX,SW_RESTORE
invoke ExitProcess,0 ; Hasta la vista! baby
ret
START endp
message loop code that could be added:
msgloop proc
LOCAL msg :MSG
LOCAL pmsg :QWORD
mov pmsg, ptr$(msg) ; get the msg structure address
jmp gmsg ; jump directly to GetMessage()
mloop:
invoke TranslateMessage,pmsg
invoke DispatchMessage,pmsg
gmsg:
test rax, rv(GetMessage,pmsg,0,0,0) ; loop until GetMessage returns zero
jnz mloop
ret
msgloop endp
Add 'call msgloop' after call to ShowWindow
Another error in your code
invoke GetLastError
invoke ShowWindow,EAX,SW_RESTORE
First should be 'invoke ShowWindow,RAX,SW_SHOW' or better: 'invoke ShowWindow,HWND1,SW_SHOW'
Second RAX overwritten by call to GetLastError so HWND1 no longer in RAX.
What is the sense of including 30,000 icons? No wonder rc.exe and polink.exe hang...
Attached source works perfectly.
porc.exe 0:4.144s
rc.exe 2:59.201s
polink 11 generated data dll, 36 601 344 bytes :thumbsup:
4:10.879s
Pelle's pope.exe can open it :thumbsup:
Hi zedd151!
I'm very pleased to receive your feebback,
well, actually you are very right about your suggestions and ideas
the only thing is that I"ve intentinally removed majority of code after creaating window just to not overbload the sample
the main idea I'd like to focus is the issue with linker working on big resoources count
I've had a need for such a strange sample due to some testing strategy plan, so I did that for that purpose but all of a sudden hit the unexpected crash of linkers
BTW, I"ve used po**.exe binaries from latest release of Pelles C (ver 11.0.0.0) and it worked like a charm - no any linker issues, despite it works very long - a couple of times and also using lots of CPU cycles..
@greenozon
I generally stick to writing 32 bit code but I saw the omission of the message loop and thought I should respond.
Yes, loading 30,000 icons would surely take a looooooong time. Even if it is only loading the same icon over and over again. Still unsure the reason for it though, your answer was somewhat cryptic.
Good to see you have your 'odd' experiment working nonetheless.
Quote from: jj2007 on October 03, 2022, 12:17:56 AM
What is the sense of including 30,000 icons? No wonder rc.exe and polink.exe hang...
Quote from: greenozon on October 03, 2022, 04:29:46 AMthe main idea I'd like to focus is the issue with linker working on big resoources count
I hate torturing my machine with 100% on one core, but I am curious, too.
RC.exe wastes almost 2 minutes of cpu time, but it succeeds in the end, producing a 35MB test2.res
polink wastes 2:24 minutes and finally crashes.
My best guess is that polink was not designed for 30,000 icons and crashes when the count reaches 16384. In fact, with 16373 icons it doesn't crash. Now it's your turn, test it with 16382, 16383, 16384 and 16385 items. Don't burn your cpu, though :cool:
Both rc and polink are obviously not designed for this high item count. It's a mere 35 MB, so arranging them in a single file should not take more than a second. For comparison, loading a 40MB text file into memory and converting it to a string array takes 35 milliseconds.
Maybe better to use LoadImage using filenames. Makes a lot of code, but less problems loading that many icons. Plus keeps the exe size down. And I always thought using 100 or so bitmaps (in resources) was bad. :tongue:
I still don't get the trend of using po***(asm, rc, link, etc) rather than the usual MS stuff. If I ever have to reassemble others sources to help debug it I always use the MS variety of tools, no matter what the original author was using.
Hi zedd,
QuoteI still don't get the trend of using po***(asm, rc, link, etc) rather than the usual MS stuff. If I ever have to reassemble others sources to help debug it I always use the MS variety of tools, no matter what the original author was using.
Pelle Orinius is a very very good coder and he regularly maintains his tools. They are MS compatible. One of the best alternatives to the MS tool set.
Hi Vortex, I was wondering if his tools do anything better or address any particular issues that ml, ml64, link, etc do not. Thanks for replying.
Z,
Pelle's tools have been super reliable for years and are generally more up to date than the Microsoft ones. In particular, POLINK produces slightly smaller executables than the Microsoft linker. I use both.
Thanks hutch. That explains a lot. :biggrin:
Hi zedd151,
QuoteIn particular, POLINK produces slightly smaller executables than the Microsoft linker.
Hutch is right, the size difference is 512 \ 1024 bytes.
Smaller file header?
Hi zedd,
The DOS header in the executables produced by Polink is smaller.
Ok. Thank you, that's what I thought. I know I said file header, but meant DOS header. Seems an insignificant savings with modern hard drive capacities.
Does anyone knows if there is a replacement of rc.exe (+rcdll.dll) by MS as it is crashing on my another testcase:
I'm talking about rc.exe 10.0.18362.1
RC : fatal error RC1000: Internal error
ExceptionCode = C0000005
ExceptionFlags = 00000000
ExceptionAddress = 000007FED28C2D88 (000007FED28B0000) "c:\masm64\bin64\RCDLL.dll"
NumberParameters = 00000002
ExceptionInformation[ 0] = 0000000000000000
ExceptionInformation[ 1] = 0000000000000000
CONTEXT:
Rax = 0000000000000000 R8 = 000000000000001C
Rbx = 0000000000000000 R9 = FFFFFFFFFFFFFFFF
Rcx = 0000000000000003 R10 = 0000000000000000
Rdx = 0000000000000000 R11 = 0000000000000000
Rsp = 00000000001ADB40 R12 = 0000000000000001
Rbp = 000000000882B660 E13 = 0000000002444940
Rsi = 0000000000000000 R14 = 000007FED290C220
Rdi = 0000000000000128 R15 = 000000000882B680
Rip = 000007FED28C2D88 EFlags = 0000000000010256
SegCs = 0000000000000033 SegDs = 000000000000002B
SegSs = 000000000000002B SegEs = 000000000000002B
SegFs = 0000000000000053 SegGs = 000000000000002B
Dr0 = 0000000000000000 Dr3 = 0000000000000000
Dr1 = 0000000000000000 Dr6 = 0000000000000000
Dr2 = 0000000000000000 Dr7 = 0000000000000000
Quote from: greenozon on October 06, 2022, 03:08:52 AMDoes anyone knows if there is a replacement of rc.exe (+rcdll.dll) by MS as it is crashing on my another testcase:
post your .rc file, maybe someone can help determine the cause for the crash better that way.
Also, is it the same version of rc.exe and rc.dll?
Even better,
attach your entire project in a
.zip file. This way other members may be able to see if a different rc.exe/rc.dll versions makes a difference. Possibly an error in the .rc file?
Hi greenozon,
You can also try Pelle's resource compiler porc.exe :
E:\PellesC\Bin>porc.exe
Pelles Resource Compiler, Version 11.00.0
Copyright (c) Pelle Orinius 1997-2021
Dependencies :
E:\PellesC\Bin>podump.exe /IMPORTS porc.exe | findstr ".dll"
KERNEL32.dll
porc.dll
Its usually the case that if you have an error in an RC script, RC.EXE will crash and leave a dead temp file in the directory where you are building the app. The solution is to fix any errors in the RC script. Also with RC.EXE, use the /v switch (verbose mode) as it can be useful in determining problems.
Pelle's tools work well and are always up to date, you can also try his resource compiler.
Yet another question on polink.exe
Goal: I'd like to generate debug info and benefit from it in either Ida or Ollydbg
what are my stept to reach the goal?
I'm using x64 bits env
I"ve tried the /DEBUG option to linker but it says
Writing debug information
POLINK: warning: Unrecognized version (241) of debug symbols in object 'tut_1.obj'; ignored.
Also when I tried to feed the generated .exe into Ida it doesn't see any debug symbols..
but it complains on another issue (not related I guess to the debug stuff)
---------------------------
Warning
---------------------------
The imports segment seems to be destroyed. This MAY mean that
the file was packed or otherwise modified in order to make it
more difficult to analyze. If you want to see the imports
segment in the original form, please reload it with the
'make imports section' checkbox cleared.
---------------------------
OK
---------------------------
polink 8 don't handle microsoft x64 debug format.
polink from 10 use own debug format.
Private PellesC x64 generated debug formats:
polink 8 PO64
polink 9 P10
polink 10 PO11
polink 11 PO11
Thanks for clarifications
what about another cmd line option of the linker:
/DEBUGTYPE
From polink 11 help:
Quote/DEBUGTYPE option (POLINK)
Syntax:
/DEBUGTYPE:{PO | COFF | BOTH}
Description:
The /DEBUGTYPE option specifies the kind of debug information placed in the executable file. It can either be Pelles C information (/DEBUGTYPE:PO), COFF information (/DEBUGTYPE:COFF), or both (/DEBUGTYPE:BOTH).
As of version 9.00, for compatibility with previous versions, /DEBUGTYPE:CV will be accepted but mapped to /DEBUGTYPE:PO.
The Pelles C debug format is the preferred format, the COFF debug format is generic and easier to produce but contains much less information.
so by specifying cmd options
/DEBUG /DEBUGTYPE:COFF
some debug info was embedded into built executable
following tests shows that neither OllyDbg x64 nor x64dbg debggers were able to benefit from that debut info
the winner is IDA (7.7) - it was able to read the debug info and show symbols inside the assembly listing!