I think I have a good handle on what needs to be done and I have been able to successfully test it somehow.
Should be sending some patches soon. Regards, Waldek On Saturday, May 7, 2022 at 12:07:51 PM UTC-4 Waldek Kozaczuk wrote: > And here is how gcc changed to use _dl_find_object() - > https://github.com/gcc-mirror/gcc/commit/790854ea7670f11c14d431c102a49181d2915965. > > It seems to be used during unwinding. > > On Saturday, May 7, 2022 at 1:32:10 AM UTC-4 Waldek Kozaczuk wrote: > >> After upgrading to newest Ubuntu 2022.04 I started seeing following >> crashes of programs using libgcc_s.so: >> >> #0 _dl_find_object (pc1=0x10000003f5ca <_Unwind_Resume+58>, >> result=0x200000200180) at linux.cc:542 >> #1 0x00001000000410f6 in _Unwind_Find_FDE () >> #2 0x000010000003d833 in ?? () >> #3 0x000010000003ead0 in ?? () >> #4 0x000010000003f5cb in _Unwind_Resume () >> #5 0x0000100000062daa in ?? () >> #6 0x0000100000075b5c in >> boost::execution_monitor::vexecute(boost::function<void ()> const&) () >> #7 0x000010000007f0a9 in boost::unit_test::framework::init(bool (*)(), >> int, char**) () >> #8 0x000010000009254d in boost::unit_test::unit_test_main(bool (*)(), >> int, char**) () >> #9 0x000000004039d001 in osv::application::run_main >> (this=0xffffa00000bd8c10) at core/app.cc:416 >> #10 0x000000004039d20d in operator() (app=<optimized out>, __closure=0x0) >> at core/app.cc:236 >> #11 _FUN () at core/app.cc:238 >> #12 0x00000000403d084a in operator() (__closure=0xffffa00000d57800) at >> libc/pthread.cc:116 >> #13 std::__invoke_impl<void, pthread_private::pthread::pthread(void* >> (*)(void*), void*, sigset_t, const >> pthread_private::thread_attr*)::<lambda()>&> (__f=...) >> at /usr/include/c++/11/bits/invoke.h:61 >> #14 std::__invoke_r<void, pthread_private::pthread::pthread(void* >> (*)(void*), void*, sigset_t, const >> pthread_private::thread_attr*)::<lambda()>&> (__fn=...) >> at /usr/include/c++/11/bits/invoke.h:154 >> #15 std::_Function_handler<void(), >> pthread_private::pthread::pthread(void* (*)(void*), void*, sigset_t, const >> pthread_private::thread_attr*)::<lambda()> >::_M_invoke(const >> std::_Any_data &) (__functor=...) at >> /usr/include/c++/11/bits/std_function.h:290 >> #16 0x000000004036b58e in sched::thread::main (this=0xffff800000f6a040) >> at core/sched.cc:1267 >> #17 sched::thread_main_c (t=0xffff800000f6a040) at >> arch/x64/arch-switch.hh:325 >> #18 0x00000000402fda03 in thread_main () at arch/x64/entry.S:116 >> >> After some digging I discovered this new function was added as per this >> patch to libc - >> https://www.mail-archive.com/[email protected]/msg275305.html >> <https://www.mail-archive.com/[email protected]/msg275305.html>. >> And there s this description: >> >> http://www.gnu.org/software/libc/manual/html_node/Dynamic-Linker-Introspection.html >> >> It is interesting that libgcc_s.so on pretty new Fedora 35 with newer gcc >> does not need this. >> >> I tried to stub something but this is not enough: >> >> struct dl_find_object >> { >> __extension__ unsigned long long int dlfo_flags; >> void *dlfo_map_start; /* Beginning of mapping containing >> address. */ >> void *dlfo_map_end; /* End of mapping. */ >> struct link_map *dlfo_link_map; >> void *dlfo_eh_frame; /* Exception handling data of the object. >> */ >> __extension__ unsigned long long int __dflo_reserved[7]; >> }; >> >> #include <osv/elf.hh> >> extern "C" int >> _dl_find_object (void *pc1, dl_find_object* result) >> { >> result->dlfo_eh_frame = 0; >> result->dlfo_link_map = 0; // where would this come from? >> auto eo = elf::get_program()->object_containing_addr(pc1); >> result->dlfo_map_start = (void*)(eo->base()); >> result->dlfo_map_end = (void*)(eo->end()); >> return 0; >> } >> >> Any suggestions would be welcome. >> >> Regards, >> Waldek >> > -- You received this message because you are subscribed to the Google Groups "OSv Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/osv-dev/bf71b9f7-161a-4e17-ba0c-958519051055n%40googlegroups.com.
