You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Would it be possible, to add afunction to get the origin library in case of a function in a dynamic library?
Taking the gcc implementation for example, which uses libbacktrace internally, it currently prints something like:
0# crashHandler at /mnt/c/Users/Febbe/workspace/xournalpp/src/core/control/CrashHandler.cpp:76
1# at :0
2# pthread_kill at :0
3# raise at :0
4# MainWindow::MainWindow(GladeSearchpath*, Control*, _GtkApplication*) at /mnt/c/Users/Febbe/workspace/xournalpp/src/core/gui/MainWindow.cpp:54
5# std::_MakeUniq<MainWindow>::__single_object std::make_unique<MainWindow, GladeSearchpath*, Control*, _GtkApplication*>(GladeSearchpath*&&, Control*&&, _GtkApplication*&&) at :0
6# on_startup at /mnt/c/Users/Febbe/workspace/xournalpp/src/core/control/XournalMain.cpp:485
7# g_closure_invoke at :0
8# at :0
9# g_signal_emit_valist at :0
10# g_signal_emit at :0
11# g_application_register at :0
12# at :0
13# g_application_run at :0
14# XournalMain::run(int, char**) at /mnt/c/Users/Febbe/workspace/xournalpp/src/core/control/XournalMain.cpp:690
Note the at :0 in case of missing debug symbols.
That results from a call to backtrace_pcinfo which only return the function name, line number and filename.
In any case I would expect to have the originating library path or at least the name in that line instead of nothing.
Since alternating, the API is not a feasible solution, a function to retrieve the so information from the pc would be useful.
Like
Would it be possible, to add afunction to get the origin library in case of a function in a dynamic library?
Taking the gcc implementation for example, which uses libbacktrace internally, it currently prints something like:
Note the
at :0
in case of missing debug symbols.That results from a call to backtrace_pcinfo which only return the function name, line number and filename.
In any case I would expect to have the originating library path or at least the name in that line instead of nothing.
Since alternating, the API is not a feasible solution, a function to retrieve the so information from the pc would be useful.
Like
or
My current solution is to call
dladdr1
to retrieve the so information. But this is not platform independent, I suppose.The text was updated successfully, but these errors were encountered: