We the extra debug printouts the crash looks like this: ELF [tid:42, /usr/lib/libgcc_s.so.1]: Instantiated ELF [tid:42, /usr/lib/libgcc_s.so.1]: The base set to: 0x00000000000a7000 and end: 0x00000000000c0450 ELF [tid:42, /usr/lib/libgcc_s.so.1]: Loading segments ELF [tid:42, /usr/lib/libgcc_s.so.1]: Loaded and mapped PT_LOAD segment at: 0x00000000000a7000 of size: 0x3000 ELF [tid:42, /usr/lib/libgcc_s.so.1]: Loaded and mapped PT_LOAD segment at: 0x00000000000aa000 of size: 0x11000 ELF [tid:42, /usr/lib/libgcc_s.so.1]: Loaded and mapped PT_LOAD segment at: 0x00000000000bb000 of size: 0x4000 ELF [tid:42, /usr/lib/libgcc_s.so.1]: Loaded and mapped PT_LOAD segment at: 0x00000000000bf000 of size: 0x2000 ELF [tid:42, /usr/lib/libgcc_s.so.1]: Loading DT_NEEDED object: libc.so.6 /usr/lib/libgcc_s.so.1: ignoring missing symbol __cpu_indicator_init /usr/lib/libgcc_s.so.1: ignoring missing symbol __cpu_model ELF [tid:42, /usr/lib/libgcc_s.so.1]: Relocated 10 symbols in DT_RELA ELF [tid:42, /usr/lib/libgcc_s.so.1]: Relocated 45 PLT symbols in DT_JMPREL ELF [tid:42, /usr/lib/libgcc_s.so.1]: versioned symbol table ELF [tid:42, /java_isolated.so]: Loading DT_NEEDED object: libc.so.6 ELF [tid:42, /java_isolated.so]: Relocated 469 symbols in DT_RELA ELF [tid:42, /java_isolated.so]: Relocated 246 PLT symbols in DT_JMPREL ELF [tid:42, /java_isolated.so]: versioned symbol table ELF [tid:253, /usr/lib/libgcc_s.so.1]: Executing DT_INIT function ELF [tid:253, /usr/lib/libgcc_s.so.1]: Finished executing DT_INIT function ELF [tid:253, /usr/lib/libgcc_s.so.1]: Executing 2 DT_INIT_ARRAYSZ functions trying to execute or access missing symbol [backtrace] 0x00000000403aeb19 <page_fault+297> 0x00000000403ad8d6 <???+1077598422> 0x00000000403609fa <elf::program::init_library(int, char**)+362> 0x0000000040226237 <osv::application::main()+71> 0x000000004044406c <???+1078214764> 0x00000000404782b9 <???+1078428345> 0x000000004040f29b <thread_main_c+43> 0x00000000403ae852 <???+1077602386>
It looks like one of the 2 functions in DT_INIT_ARRAYSZ references one of the missing symbols (per versym). Probably __cpu_indicator_init. So I wonder that instead of skipping deprecated symbols, we should tweak the versioning logic to make it find symbols IF referenced by the object itself. Other part of the Drepper's text - https://www.akkadia.org/drepper/symbol-versioning - seems to suggest that: "vna_other Contains version index unique for the file which is used in the version symbol table. If the highest bit (bit 15) is set this is a hidden symbol which cannot be referenced *from outside the object*." On Saturday, November 30, 2019 at 1:16:46 PM UTC-5, Waldek Kozaczuk wrote: > > Or is the issue that given that __cpu_indicator_init is a constructor > function that is in symver and deprecated > 4.8 we should also skip > calling deprecated INIT functions ? > > On Sat, Nov 30, 2019 at 00:34 Waldek Kozaczuk <[email protected]> > wrote: > >> Here is the change made to libgcc.so 4 years ago that seems to be causing >> this problem - >> https://github.com/gcc-mirror/gcc/commit/4b5fb32aba30762e0d8c9e75d1b46b47bee5eeb4 >> . >> >> These 2 missing (hidden with versioning) are present in libgcc.a: >> readelf -s /usr/lib/gcc/x86_64-linux-gnu/9/libgcc.a | grep >> __cpu_indicator_init >> 13: 0000000000000290 905 FUNC GLOBAL HIDDEN 4 >> __cpu_indicator_init >> >> We stopped linking libgcc.a as whole-archive year ago but even if we >> still did it would not help us given this symbol is hidden. >> >> I wonder how we should solve it. >> >> >> On Thursday, November 28, 2019 at 3:18:48 PM UTC-5, Waldek Kozaczuk wrote: >>> >>> This is related to https://github.com/cloudius-systems/osv/issues/743. >>> >>> I have been trying to eliminate ancient libgcc_s.so from >>> usr.manifest.skel and replace it with the version from host. When I do that >>> most (C++ only?) apps fail like so: >>> >>> Cmdline: /java_isolated.so -cp /tests/java/tests.jar >>> io.osv.TestDomainPermissions >>> /usr/lib/libgcc_s.so.1: ignoring missing symbol __cpu_indicator_init >>> /usr/lib/libgcc_s.so.1: ignoring missing symbol __cpu_model >>> trying to execute or access missing symbol >>> [backtrace] >>> 0x000000004039d6ab <page_fault+267> >>> 0x000000004039c486 <???+1077527686> >>> 0x00000000403528ca <elf::program::init_library(int, char**)+362> >>> 0x0000000040223cdd <osv::application::main()+61> >>> 0x000000004042deb8 <???+1078124216> >>> 0x000000004045fdb5 <???+1078328757> >>> 0x00000000403f9ce7 <thread_main_c+39> >>> 0x000000004039d402 <???+1077531650> >>> >>> I somehow discovered it has to do with versioning. So when I undo my >>> commit that fixed libnuma (see >>> https://github.com/cloudius-systems/osv/commit/ed1eed7a567ec17138c65f0a5628c2311603c712 >>> ). >>> >>> So if I manually undo these changes the error disappears. It is >>> obviously related to these warnings: >>> /usr/lib/libgcc_s.so.1: ignoring missing symbol __cpu_indicator_init >>> /usr/lib/libgcc_s.so.1: ignoring missing symbol __cpu_model >>> >>> What is actually going on? And what is the right fix? >>> >>> I found couple of the things that might be related: >>> >>> https://bugzilla.redhat.com/show_bug.cgi?id=1688766 >>> >>> http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-devtools/gcc/gcc-9.2/0032-libgcc_s-Use-alias-for-__cpu_indicator_init-instead-.patch?h=master >>> >>> Waldek >>> >>> >>> >>> >>> -- >> You received this message because you are subscribed to a topic in the >> Google Groups "OSv Development" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/osv-dev/HZHzeG_5IqM/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/osv-dev/e5b7c460-b7d5-438f-9001-5546f65c4894%40googlegroups.com >> >> <https://groups.google.com/d/msgid/osv-dev/e5b7c460-b7d5-438f-9001-5546f65c4894%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- 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/ca3133df-a5bf-42bb-84da-b1963aef3d3d%40googlegroups.com.
