dbghelp detached from wine into standalone windows dll...

[Tarmo Pikaro]

Hi !
> I think wrapping can go in either direction, but you must admit that writing:
>
> len = utf8zestimate(searchPath);
>
> is shorter than:
>
> len = MultiByteToWideChar(CP_ACP, 0, searchPath, -1, NULL, 0);
>
> by 6-1 = 5 parameters, 

> It's also completely non-standard. In Wine, we use Windows APIs wherever
> possible.

I think we could handle standardization through providing necessary functionality and covering that functionality by testing. Do you have testing for windows api's MultiByteToWideChar/... ?
Btw - noticed that wine is using 2 = sizeof(wchar_t), like it's in windows at the moment, butin linux sizeof(wchar_t) == 4, so suspect my code won't work out of box. Need to check deeper later on.


> Yes, but I would like to start from basics - enable functionality initially, and worry about which dll
> exports and what later on. I think we could have even our own (application) specific "standard" API.
>
> Btw - I have tried to load from wine / LoadLibrary linux shared object, but could not. Tried something like this:
>
>    void stackCallbacker()
>    {
>        printf("%s", g3::internal::stackdump().c_str());
>    }
>
>    typedef void(*func)(void);
>    typedef void(*fcallFunc)(func);
>
>    int main(int argc, char **argv)
>    {
>        //HMODULE h = LoadLibraryA("dll.dll");
>        const char* dllName = "dll";
>        //const char* dllName = "/mnt/c/Prototyping/dbghelp2_dev2/bin/Release_x86/dll.so";
>        HMODULE h = LoadLibraryA(dllName);
>        if (h == 0)
>        {
>            printf("Failed to load '%s'\n", dllName);
>            return 0;
>        }
>
>        fcallFunc fc;
>        *((FARPROC*)&fc) = GetProcAddress(h, "DoTestCall");
>
>        printf("Calling dll -> DoTestCall ...\n");
>        fc(stackCallbacker);
>        printf("call ok.");
>
> But wine refuses to load dll.so by relative or absolute path. Does wine supports this ?

> It works if the .so file was built as a Wine library, with an embedded
> PE header. It's not possible to load a plain .so lib, since there's no
> way to return a valid HMODULE for it.
Do I need to use wine specific compiler or linker for that purpose ?

I have almost compiled dbghelp to linux (standalone), have now ~ 10 linking errors, but now also started to wonderhow do I test overall system.
At the moment whole stack all resoving procedure can be divided into two steps:1. Resolve call stack (ip's of execution stack).2. Resolve symbol information on call stack.
1 at the moment is done using following for loop:
      for (size_t index = 0; index < frame_pointers.size(); ++index)      {         if (StackWalk64(machine_type,                         GetCurrentProcess(),                         GetCurrentThread(),                         &frame,                         context,                         NULL,                         SymFunctionTableAccess64,                         SymGetModuleBase64,                         NULL)) {            frame_pointers[index] = frame.AddrPC.Offset;         } else {            break;         }      }
I've started to wonder how step 1 can be implemented for linux, and one approach is indeed to use same call sequence, but then I will need to wrap up ReadProcessMemory for linux, or I could use some existing library to do the same thing.
I went to github and made a search for "unw_get_proc_name SymGetLineFromAddr64 callstack"and find out that there already exists portable version of call stack determination, residing in OVR_DebugHelp.cpp.
For example this one: https://github.com/Magnusnorrby/MolyRift/blob/master/Kernel/OVR_DebugHelp.cpp
where step 1 is implemented in here: https://github.com/Magnusnorrby/MolyRift/blob/master/Kernel/OVR_DebugHelp.cpp#L1142
Generally for linux they use libunwind library.
Quickly googling for libunwind gave me 3 different libraries:1. libunwind / llvm (c++ based)2. original libunwind/gnu: https://www.nongnu.org/libunwind/ (C based)3. Unity specific / android libunwind: https://github.com/Unity-Technologies/android-libunwind
Uff... That's heavy, so many alternatives, and of course tightly bound to compiler which is used (gcc / clang).
I suspect that get call stack can be generic function in itself, and even dbghelp implementation can be used - but I do care about it's functionality and it's performance.
In my own implementation (long time ago):https://sourceforge.net/projects/diagnostic/http://diagnostic.sourceforge.net/index.html
https://sourceforge.net/p/diagnostic/svn/HEAD/tree/src/ResolveStack.cpp / see CaptureStackBackTracePro I've concluded to use RtlVirtualUnwind (64 bit) simply because StackWalk64 (native windows implementation)was too slow, also did not work out of box for managed code.
I've noticed that in wine's dbghelp implementation there is also some disassembly approach when resolving call stack, might slow down call stack query, but might also bring more reliable call stack determination.
Do you have any unit tests for StackWalk64 - I suspect they are not so trivial to implement, since depends on executing program.
In diagnostic I can "hook" external application to monitor all memory allocation and free requests, also can use it also forperformance measuring of application slow down / call stack reliability determination.
But this approach of course is applicable for windows only. Haven't investigated using hooks on linux.
Btw - I've raised issue for dotnetclr on c++ mixed mode call stack determination:
https://github.com/dotnet/coreclr/issues/23681





  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20190609/8e0093d3/attachment.html>