<html><head></head><body><div class="ydp348a5932yahoo-style-wrap" style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif; font-size: 13px;"><div>Hi !</div><div><br></div><div>I was looking for here and there for portable (windows & linux) call stack determination functionality - but could not find any.</div><div><br></div><div>I have some experience with call stack determination, but only on windows - made memory leak detection utility for windows once upon a time.</div><div><br></div><div>But all API's with which I have played around are windows based. Now wanted to go deeper with call stack determination and moreover </div><div>make functionality portable - to start from windows & linux, later on expanding to android. </div><div><br></div><div>Brief analysis showed a lot of complexity without any clear / good / portable library.</div><div><br></div><div>Analysis came upon dbghelp.dll which is implemented in Wine - I have noticed that besides windows PE file format it contains also </div><div>support for loading debug information for DWARF / ELF file format. I've got curious, and started to prototype.</div><div><br></div><div>I've made windows project where I have dragged some parts of wine functionality. (LGPL licensed)</div><div><br></div><div>Something similar was done once in here: <span><a href="https://github.com/vtjnash/dbghelp2" rel="nofollow" target="_blank">https://github.com/vtjnash/dbghelp2</a></span></div><div><br></div><div>but he have used cross compilation toolchain, I wanted to use Visual studio + microsoft compiler.</div><div><br></div><div>My own repository is located here:</div><div><span><a href="https://github.com/tapika/dbghelp2" rel="nofollow" target="_blank">https://github.com/tapika/dbghelp2</a></span><br></div><div><br></div><div>My prime target is 64-bit windows, 32-bit is nice-to-have.</div><div><br></div><div>Well - dll itself is nice, but I needed test application. Quick analysis came upon <span><a href="https://github.com/KjellKod/g3log" rel="nofollow" target="_blank">https://github.com/KjellKod/g3log</a> </span></div><div>that logger was using dbghelp - official microsoft distribution.</div><div><br></div><div>After some fighting with compilation and linking errors I've managed to detach dbghelp from wine into separate .dll, I've called it dbghelp2.dll.</div><div><br></div><div>But at run-time library refused to work. </div><div><br></div><div>I'll try to list here problems upon which I've came accross:</div><div><br></div><div>32-bit compilation:</div><div><br></div><div>A lot of unsupported traces in base functionality:</div><div><br></div><div><div><div>976c:fixme:dbghelp_msc:c:\prototyping\dbghelp2\dlls\dbghelp\msc.c 725: Unsupported type 1404 in ENUM field list</div><div>976c:fixme:dbghelp_msc:c:\prototyping\dbghelp2\dlls\dbghelp\msc.c 2038: Unsupported symbol id 1124</div><div>976c:fixme:dbghelp_msc:c:\prototyping\dbghelp2\dlls\dbghelp\msc.c 123: 00000000: 06 00 24 11 73 74 64 00 ..$.std. </div><div>976c:fixme:dbghelp_msc:c:\prototyping\dbghelp2\dlls\dbghelp\msc.c 2038: Unsupported symbol id 1124</div><div>976c:fixme:dbghelp_msc:c:\prototyping\dbghelp2\dlls\dbghelp\msc.c 123: 00000000: 1a 00 24 11 5f 48 61 73 5f 41 44 4c 5f 73 77 61 ..$._Has_ADL_swa</div><div>976c:fixme:dbghelp_msc:c:\prototyping\dbghelp2\dlls\dbghelp\msc.c 123: 00000010: 70 5f 64 65 74 61 69 6c 00 00 00 00 p_detail.... </div><div>976c:fixme:dbghelp_msc:c:\prototyping\dbghelp2\dlls\dbghelp\msc.c 2038: Unsupported symbol id 1124</div><div>976c:fixme:dbghelp_msc:c:\prototyping\dbghelp2\dlls\dbghelp\msc.c 123: 00000000: 0a 00 24 11 72 65 6c 5f 6f 70 73 00 ..$.rel_ops. </div><div>...</div></div><div><br></div>same problems occurs in 64-bit compilation.</div><div><br></div><div>Finally call stack determination refused to work:</div><div><div><div>976c:fixme:dbghelp:c:\prototyping\dbghelp2\dlls\dbghelp\stack.c 59: Failed to linearize address 771f:7000 (mode 0)</div><div><br></div></div>64-bit compilation:</div><div><br></div><div>I've noticed that addressing uses 32-bit unsigned long, while 64-bit addressing mode requires uint64_t. Besides this g3log also was using incorrect API's - I've </div><div><div><div>ended up replacing SymGetSymFromAddr64 with SymFromAddr.</div><div><br></div></div>call stack determination seems to work, also function resolving, but not source code position or line information, what Microsoft dbghelp.dll can do out of box.</div><div><br></div><div>So now dbghelp2.dll can determine stack like this:</div><div><br></div><div><div><div>*******<span style="white-space: pre-wrap;"> </span>STACKDUMP *******</div><div>stack using dbghelp2.dll</div><div><br></div><div>stack dump [0]<span style="white-space: pre-wrap;"> </span> std::basic_string<char,std::char_traits<char>,std::allocator<char> >::append</div><div>stack dump [1]<span style="white-space: pre-wrap;"> </span> std::basic_string<char,std::char_traits<char>,std::allocator<char> >::append</div><div>stack dump [2]<span style="white-space: pre-wrap;"> </span> example_fatal::tryToKillWithAccessingIllegalPointer</div><div>stack dump [3]<span style="white-space: pre-wrap;"> </span> main</div><div>stack dump [4]<span style="white-space: pre-wrap;"> </span> invoke_main</div><div>stack dump [5]<span style="white-space: pre-wrap;"> </span> __scrt_common_main_seh</div><div>stack dump [6]<span style="white-space: pre-wrap;"> </span> __scrt_common_main</div><div>stack dump [7]<span style="white-space: pre-wrap;"> </span> mainCRTStartup</div><div>stack dump [8]<span style="white-space: pre-wrap;"> </span></div><div>stack dump [9]<span style="white-space: pre-wrap;"> </span></div><div><br></div></div>while Microsoft's implementation determines it like this:</div><div><div><div>stack dump [0]<span style="white-space: pre-wrap;"> </span>c:\program files (x86)\microsoft visual studio\2017\enterprise\vc\tools\msvc\14.16.27023\include\xstring L: 2571 std::basic_string<char,std::char_traits<char>,std::allocator<char> >::append</div><div>stack dump [1]<span style="white-space: pre-wrap;"> </span>c:\program files (x86)\microsoft visual studio\2017\enterprise\vc\tools\msvc\14.16.27023\include\xstring L: 2593 std::basic_string<char,std::char_traits<char>,std::allocator<char> >::append</div><div>stack dump [2]<span style="white-space: pre-wrap;"> </span>c:\prototyping\dbghelp2\g3log\example\main_sigsegv.cpp L: 52 example_fatal::tryToKillWithAccessingIllegalPointer</div><div>stack dump [3]<span style="white-space: pre-wrap;"> </span>c:\prototyping\dbghelp2\g3log\example\main_sigsegv.cpp L: 115 main</div><div>stack dump [4]<span style="white-space: pre-wrap;"> </span>d:\agent\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl L: 79 invoke_main</div><div>stack dump [5]<span style="white-space: pre-wrap;"> </span>d:\agent\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl L: 288 __scrt_common_main_seh</div><div>stack dump [6]<span style="white-space: pre-wrap;"> </span>d:\agent\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl L: 331 __scrt_common_main</div><div>stack dump [7]<span style="white-space: pre-wrap;"> </span>d:\agent\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_main.cpp L: 17 mainCRTStartup</div><div>stack dump [8]<span style="white-space: pre-wrap;"> </span> BaseThreadInitThunk</div><div>stack dump [9]<span style="white-space: pre-wrap;"> </span> RtlUserThreadStart</div><div><br></div></div><div>Noticed stack frames [8] & [9] contains additional functions, not available in wine port.</div><br></div><div>Here is 64-bit enabling commit:</div><div><br></div><div><span><a href="https://github.com/tapika/dbghelp2/commit/3a3e9daacae14c4f73585aeff4ef53a207a9f55d" rel="nofollow" target="_blank">https://github.com/tapika/dbghelp2/commit/3a3e9daacae14c4f73585aeff4ef53a207a9f55d</a></span><br></div><div><br></div><div>Basically my intention was to prototype that it's possible to determine call stack using wine dbghelp parts. </div><div><br></div><div>- Does it makes any sense to try to make my dbghelp prototype be more or less official / or create such version which would be suitable for wine and for standalone compilation ?</div><div><br></div><div>- I would be interested in further development of dbghelp - as standalone dll / so independently from wine.</div><div><br></div><div>At the moment dbghelp serves like read / parse of existing file formats (PE & ELF), has anyone considered of expanding support towards generation of same file formats ?</div><div><br></div><div>See also CV2PDB: <span><a href="https://github.com/rainers/cv2pdb" rel="nofollow" target="_blank">https://github.com/rainers/cv2pdb</a></span></div><div>clang pdb generation support: <span><a href="http://blog.llvm.org/2017/08/llvm-on-windows-now-supports-pdb-debug.html" rel="nofollow" target="_blank">http://blog.llvm.org/2017/08/llvm-on-windows-now-supports-pdb-debug.html</a></span></div><div><br></div><div><br></div><div class="ydp348a5932signature">-- Have a nice day!<div> Tarmo.</div><div><br></div><div><br></div></div></div></body></html>