On Sat, Nov 30, 2019 at 11:49 PM Waldek Kozaczuk <[email protected]>
wrote:

> 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*."
>
>
>
Sounds right. In general, the phrase "hidden symbol" usually means that it
is hidden from other objects - not that it is completely unusable.


>
> 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
> <https://groups.google.com/d/msgid/osv-dev/ca3133df-a5bf-42bb-84da-b1963aef3d3d%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/CANEVyjv1QnFVMNFUphE%2Bro1OR_z%2BpnohTtKCj3Yp%2B32ih5Y7ew%40mail.gmail.com.

Reply via email to