<html><head></head><body><div class="ydpe603399byahoo-style-wrap" style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif; font-size: 13px;"><div><div>Hi !</div><div><br></div><div class="ydpe603399bsignature"><span style="color: rgb(38, 40, 42);">> I think wrapping can go in either direction, but you must admit that writing:</span><br></div></div></div><div id="ydpdd14240byahoo_quoted_0311046026" class="ydpdd14240byahoo_quoted"><div style="font-family:'Helvetica Neue', Helvetica, Arial, sans-serif;font-size:13px;color:#26282a;"><div><div dir="ltr">><br clear="none">> len = utf8zestimate(searchPath);<br clear="none">><br clear="none">> is shorter than:<br clear="none">><br clear="none">> len = MultiByteToWideChar(CP_ACP, 0, searchPath, -1, NULL, 0);<br clear="none">><br clear="none">> by 6-1 = 5 parameters, <br clear="none"><br clear="none">> It's also completely non-standard. In Wine, we use Windows APIs wherever<br clear="none">> possible.<br clear="none"><br>I think we could handle standardization through providing necessary functionality and covering </div><div dir="ltr">that functionality by testing. Do you have testing for windows api's <span><span style="color: rgb(38, 40, 42); font-family: Helvetica Neue, Helvetica, Arial, sans-serif;">MultiByteToWideChar/... ?</span></span></div><div dir="ltr"><br></div><div dir="ltr">Btw - noticed that wine is using 2 = sizeof(<span><span style="color: rgb(38, 40, 42); font-family: Helvetica Neue, Helvetica, Arial, sans-serif;">wchar_t</span></span>), like it's in windows at the moment, but</div><div dir="ltr">in linux sizeof(wchar_t) == 4, so suspect my code won't work out of box. Need to check deeper later on.<br><br><br clear="none">> Yes, but I would like to start from basics - enable functionality initially, and worry about which dll<br clear="none">> exports and what later on. I think we could have even our own (application) specific "standard" API.<br clear="none">><br clear="none">> Btw - I have tried to load from wine / LoadLibrary linux shared object, but could not. Tried something like this:<br clear="none">><br clear="none">> void stackCallbacker()<br clear="none">> {<br clear="none">> printf("%s", g3::internal::stackdump().c_str());<br clear="none">> }<br clear="none">><br clear="none">> typedef void(*func)(void);<br clear="none">> typedef void(*fcallFunc)(func);<br clear="none">><br clear="none">> int main(int argc, char **argv)<br clear="none">> {<br clear="none">> //HMODULE h = LoadLibraryA("dll.dll");<br clear="none">> const char* dllName = "dll";<br clear="none">> //const char* dllName = "/mnt/c/Prototyping/dbghelp2_dev2/bin/Release_x86/dll.so";<br clear="none">> HMODULE h = LoadLibraryA(dllName);<br clear="none">> if (h == 0)<br clear="none">> {<br clear="none">> printf("Failed to load '%s'\n", dllName);<br clear="none">> return 0;<br clear="none">> }<br clear="none">><br clear="none">> fcallFunc fc;<br clear="none">> *((FARPROC*)&fc) = GetProcAddress(h, "DoTestCall");<br clear="none">><br clear="none">> printf("Calling dll -> DoTestCall ...\n");<br clear="none">> fc(stackCallbacker);<br clear="none">> printf("call ok.");<br clear="none">><br clear="none">> But wine refuses to load dll.so by relative or absolute path. Does wine supports this ?<br clear="none"><br clear="none">> It works if the .so file was built as a Wine library, with an embedded<br clear="none">> PE header. It's not possible to load a plain .so lib, since there's no<br clear="none">> way to return a valid HMODULE for it.</div><div dir="ltr"><br></div><div dir="ltr">Do I need to use wine specific compiler or linker for that purpose ?</div><div dir="ltr"><br></div><div dir="ltr"><br><div class="ydpdd14240byqt8000837821" id="ydpdd14240byqtfd30924"><div><div>I have almost compiled dbghelp to linux (standalone), have now ~ 10 linking errors, but now also started to wonder</div><div>how do I test overall system.</div><div><br></div><div>At the moment whole stack all resoving procedure can be divided into two steps:</div><div>1. Resolve call stack (ip's of execution stack).</div><div>2. Resolve symbol information on call stack.</div><div><br></div><div>1 at the moment is done using following for loop:</div><div><br></div><div> for (size_t index = 0; index < frame_pointers.size(); ++index)</div><div> {</div><div> if (StackWalk64(machine_type,</div><div> GetCurrentProcess(),</div><div> GetCurrentThread(),</div><div> &frame,</div><div> context,</div><div> NULL,</div><div> SymFunctionTableAccess64,</div><div> SymGetModuleBase64,</div><div> NULL)) {</div><div> frame_pointers[index] = frame.AddrPC.Offset;</div><div> } else {</div><div> break;</div><div> }</div><div> }</div><div><br></div><div>I've started to wonder how step 1 can be implemented for linux, </div><div>and one approach is indeed to use same call sequence, but then I will need to wrap up ReadProcessMemory </div><div>for linux, or I could use some existing library to do the same thing.</div><div><br></div><div>I went to github and made a search for "unw_get_proc_name SymGetLineFromAddr64 callstack"</div><div>and find out that there already exists portable version of call stack determination, residing in OVR_DebugHelp.cpp.</div><div><br></div><div>For example this one: https://github.com/Magnusnorrby/MolyRift/blob/master/Kernel/OVR_DebugHelp.cpp</div><div><br></div><div>where step 1 is implemented in here: https://github.com/Magnusnorrby/MolyRift/blob/master/Kernel/OVR_DebugHelp.cpp#L1142</div><div><br></div><div>Generally for linux they use libunwind library.</div><div><br></div><div>Quickly googling for libunwind gave me 3 different libraries:</div><div>1. libunwind / llvm (c++ based)</div><div>2. original libunwind/gnu: https://www.nongnu.org/libunwind/ (C based)</div><div>3. Unity specific / android libunwind: https://github.com/Unity-Technologies/android-libunwind</div><div><br></div><div>Uff... That's heavy, so many alternatives, and of course tightly bound to compiler which is used (gcc / clang).</div><div><br></div><div>I suspect that get call stack can be generic function in itself, and even dbghelp implementation can be used - but I </div><div>do care about it's functionality and it's performance.</div><div><br></div><div>In my own implementation (long time ago):</div><div>https://sourceforge.net/projects/diagnostic/</div><div>http://diagnostic.sourceforge.net/index.html</div><div><br></div><div>https://sourceforge.net/p/diagnostic/svn/HEAD/tree/src/ResolveStack.cpp / see CaptureStackBackTracePro </div><div>I've concluded to use RtlVirtualUnwind (64 bit) simply because StackWalk64 (native windows implementation)</div><div>was too slow, also did not work out of box for managed code.</div><div><br></div><div>I've noticed that in wine's dbghelp implementation there is also some disassembly approach when resolving call stack, </div><div>might slow down call stack query, but might also bring more reliable call stack determination.</div><div><br></div><div>Do you have any unit tests for StackWalk64 - I suspect they are not so trivial to implement, since depends on executing program.</div><div><br></div><div>In diagnostic I can "hook" external application to monitor all memory allocation and free requests, also can use it also for</div><div>performance measuring of application slow down / call stack reliability determination.</div><div><br></div><div>But this approach of course is applicable for windows only. Haven't investigated using hooks on linux.</div><div><br></div><div>Btw - I've raised issue for dotnetclr on c++ mixed mode call stack determination:</div><div><br></div><div>https://github.com/dotnet/coreclr/issues/23681</div><div><br></div><div><br></div></div></div><div class="ydpdd14240byqt8000837821" id="ydpdd14240byqtfd30924"><br></div><div class="ydpdd14240byqt8000837821" id="ydpdd14240byqtfd30924"><br></div><div class="ydpdd14240byqt8000837821" id="ydpdd14240byqtfd30924"><br></div><div class="ydpdd14240byqt8000837821" id="ydpdd14240byqtfd30924"><br></div></div></div>
</div>
</div></body></html>