I have almost compiled dbghelp to linux (standalone), have now ~ 10 linking errors, but now also started to wonder
how 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 for
performance 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