* MUSL issue while loading C++ lib
@ 2016-01-21 16:21 N Jain
2016-01-21 17:12 ` Szabolcs Nagy
0 siblings, 1 reply; 8+ messages in thread
From: N Jain @ 2016-01-21 16:21 UTC (permalink / raw)
To: musl
[-- Attachment #1: Type: text/plain, Size: 422 bytes --]
Hi,
I am trying to dynamically link the c++ application and facing issue where
MUSL gives following print -
Error relocating /lib/libstdc++.so.6: _Unwind_Resume_or_Rethrow: symbol not
found
Error relocating /lib/libstdc++.so.6: _Unwind_GetLanguageSpecificData:
symbol not found
Its coming from do_relocs function. I can see the c libraries are not
having any issues so wondering what could be going wrong ?
Thanks,
NJ
[-- Attachment #2: Type: text/html, Size: 567 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: MUSL issue while loading C++ lib
2016-01-21 16:21 MUSL issue while loading C++ lib N Jain
@ 2016-01-21 17:12 ` Szabolcs Nagy
2016-01-21 19:05 ` N Jain
0 siblings, 1 reply; 8+ messages in thread
From: Szabolcs Nagy @ 2016-01-21 17:12 UTC (permalink / raw)
To: musl
* N Jain <jain61@gmail.com> [2016-01-21 11:21:57 -0500]:
>
> Error relocating /lib/libstdc++.so.6: _Unwind_Resume_or_Rethrow: symbol not
> found
> Error relocating /lib/libstdc++.so.6: _Unwind_GetLanguageSpecificData:
> symbol not found
>
these symbols should be defined in libgcc_s.so.1
which is linked to c++ code by gcc.
sounds like a gcc toolchain issue, if you cannot
figure it out then post
echo 'int main(){}' |g++ -xc++ -
readelf -ld ./a.out
strace /lib/ld-musl-*.so.1 ./a.out
readelf -d /lib/libstdc++.so.6
readelf -aW /lib/libstdc++.so.6 |grep Unwind
readelf -aW /lib/libgcc_s.so.1 |grep Unwind
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: MUSL issue while loading C++ lib
2016-01-21 17:12 ` Szabolcs Nagy
@ 2016-01-21 19:05 ` N Jain
2016-01-21 20:06 ` Szabolcs Nagy
0 siblings, 1 reply; 8+ messages in thread
From: N Jain @ 2016-01-21 19:05 UTC (permalink / raw)
To: musl, Szabolcs Nagy
[-- Attachment #1: Type: text/plain, Size: 15465 bytes --]
Hi Szabolcs,
I am having one c and other cpp file and using g++ for linking.
I do have libgcc_s.so.1 lib added.
When I looked into generated elf I do see .so dependencies but order of
libgcc_s.so.1 is second.
I am assuming this is not the problem.
0x00000001 (NEEDED) Shared library: [libstdc++.so.6]
0x00000001 (NEEDED) Shared library: [libgcc_s.so.1]
0x00000001 (NEEDED) Shared library: [libc.so]
>
> > these symbols should be defined in libgcc_s.so.1
> > which is linked to c++ code by gcc.
>
Also searching online I saw some issues with versions for
GLIBCXX but don't know how to confirm if this is not the problem with MUSL
toolchain I generated.
ersion needs section '.gnu.version_r' contains 1 entries:
Addr: 0x0000000000010634 Offset: 0x000634 Link: 4 (.dynstr)
000000: Version: 1 File: libstdc++.so.6 Cnt: 3
0x0010: Name: GLIBCXX_3.4.9 Flags: none Version: 4
0x0020: Name: GLIBCXX_3.4.11 Flags: none Version: 3
0x0030: Name: GLIBCXX_3.4 Flags: none Version: 2
> > sounds like a gcc toolchain issue, if you cannot
> > figure it out then post
>
> > echo 'int main(){}' |g++ -xc++ -
>
I am not sure where to issue this command ?
>
> > readelf -ld ./a.out
>
Result
------------
Elf file type is EXEC (Executable file)
Entry point 0x109fc
There are 7 program headers, starting at offset 52
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
EXIDX 0x000c08 0x00010c08 0x00010c08 0x00008 0x00008 R 0x4
PHDR 0x000034 0x00010034 0x00010034 0x000e0 0x000e0 R E 0x4
INTERP 0x000114 0x00010114 0x00010114 0x00016 0x00016 R 0x1
[Requesting program interpreter: /lib/ld-musl-arm.so.1]
LOAD 0x000000 0x00010000 0x00010000 0x00c14 0x00c14 R E 0x10000
LOAD 0x000c14 0x00020c14 0x00020c14 0x00154 0x0020c RW 0x10000
DYNAMIC 0x000c24 0x00020c24 0x00020c24 0x000f8 0x000f8 RW 0x4
GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x10
Section to Segment mapping:
Segment Sections...
00 .ARM.exidx
01
02 .interp
03 .interp .hash .dynsym .dynstr .gnu.version .gnu.version_r
.rel.dyn .rel.plt .init .plt .text .fini .rodata .ARM.exidx .eh_frame
04 .init_array .fini_array .jcr .dynamic .got .data .bss
05 .dynamic
06
Dynamic section at offset 0xc24 contains 26 entries:
Tag Type Name/Value
0x00000001 (NEEDED) Shared library: [libstdc++.so.6]
0x00000001 (NEEDED) Shared library: [libgcc_s.so.1]
0x00000001 (NEEDED) Shared library: [libc.so]
0x0000000c (INIT) 0x106fc
0x0000000d (FINI) 0x10b68
0x00000019 (INIT_ARRAY) 0x20c14
0x0000001b (INIT_ARRAYSZ) 8 (bytes)
0x0000001a (FINI_ARRAY) 0x20c1c
0x0000001c (FINI_ARRAYSZ) 4 (bytes)
0x00000004 (HASH) 0x1012c
0x00000005 (STRTAB) 0x103bc
0x00000006 (SYMTAB) 0x101ec
0x0000000a (STRSZ) 573 (bytes)
0x0000000b (SYMENT) 16 (bytes)
0x00000015 (DEBUG) 0x0
0x00000003 (PLTGOT) 0x20d1c
0x00000002 (PLTRELSZ) 120 (bytes)
0x00000014 (PLTREL) REL
0x00000017 (JMPREL) 0x10684
0x00000011 (REL) 0x10674
0x00000012 (RELSZ) 16 (bytes)
0x00000013 (RELENT) 8 (bytes)
0x6ffffffe (VERNEED) 0x10634
0x6fffffff (VERNEEDNUM) 1
0x6ffffff0 (VERSYM) 0x105fa
0x00000000 (NULL) 0x0
> > strace /lib/ld-musl-*.so.1 ./a.out
>
I don't have strace capability in my toolchain.
> > readelf -d /lib/libstdc++.so.6
>
Result
------------
Dynamic section at offset 0x126f00 contains 28 entries:
Tag Type Name/Value
0x00000001 (NEEDED) Shared library: [libc.so]
0x00000001 (NEEDED) Shared library: [libgcc_s.so.1]
0x0000000e (SONAME) Library soname: [libstdc++.so.6]
0x0000000c (INIT) 0x68280
0x0000000d (FINI) 0x1100f8
0x00000019 (INIT_ARRAY) 0x1329ec
0x0000001b (INIT_ARRAYSZ) 44 (bytes)
0x0000001a (FINI_ARRAY) 0x132a18
0x0000001c (FINI_ARRAYSZ) 4 (bytes)
0x00000004 (HASH) 0x114
0x00000005 (STRTAB) 0x1c8a8
0x00000006 (SYMTAB) 0x75c8
0x0000000a (STRSZ) 259844 (bytes)
0x0000000b (SYMENT) 16 (bytes)
0x00000003 (PLTGOT) 0x137000
0x00000002 (PLTRELSZ) 6832 (bytes)
0x00000014 (PLTREL) REL
0x00000017 (JMPREL) 0x667d0
0x00000011 (REL) 0x5eef0
0x00000012 (RELSZ) 30944 (bytes)
0x00000013 (RELENT) 8 (bytes)
0x6ffffffc (VERDEF) 0x5ea08
0x6ffffffd (VERDEFNUM) 34
0x6ffffffe (VERNEED) 0x5eeb0
0x6fffffff (VERNEEDNUM) 1
0x6ffffff0 (VERSYM) 0x5bfac
0x6ffffffa (RELCOUNT) 796
0x00000000 (NULL) 0x0
> > readelf -aW /lib/libstdc++.so.6 |grep Unwind
>
Result
------------
00137214 00036116 R_ARM_JUMP_SLOT 00000000 _Unwind_GetRegionStart
00137254 0003d116 R_ARM_JUMP_SLOT 00000000 _Unwind_GetTextRelBase
00137268 0003de16 R_ARM_JUMP_SLOT 00000000 _Unwind_RaiseException
00137330 00051c16 R_ARM_JUMP_SLOT 00000000
_Unwind_Resume_or_Rethrow
00137510 00083616 R_ARM_JUMP_SLOT 00000000
_Unwind_GetLanguageSpecificData
0013757c 0008d916 R_ARM_JUMP_SLOT 00000000 _Unwind_VRS_Get
001377f4 000d0016 R_ARM_JUMP_SLOT 00000000 _Unwind_Complete
00137954 000ee216 R_ARM_JUMP_SLOT 00000000 _Unwind_GetDataRelBase
00137b2c 0011f216 R_ARM_JUMP_SLOT 00000000 _Unwind_VRS_Set
00137bec 00131d16 R_ARM_JUMP_SLOT 00000000 _Unwind_DeleteException
00137c70 0013d416 R_ARM_JUMP_SLOT 00000000 _Unwind_Resume
Unwind table index '.ARM.exidx' at offset 0x11d9e4 contains 2164 entries:
0x6e11c <_ZL21base_of_encoded_valuehP15_Unwind_Context>: 0x80a8b0b0
0x6e190 <_ZL17parse_lsda_headerP15_Unwind_ContextPKhP16lsda_header_info>:
0x80acb0b0
0x6e990
<_ZL33__gxx_dependent_exception_cleanup19_Unwind_Reason_CodeP21_Unwind_Control_Block>:
0x80a8b0b0
0x6ee4c <_ZL22free_any_cxa_exceptionP21_Unwind_Control_Block>: 0x1
[cantunwind]
0x6f00c
<_ZL23__gxx_exception_cleanup19_Unwind_Reason_CodeP21_Unwind_Control_Block>:
0x80a8b0b0
865: 00000000 0 FUNC GLOBAL DEFAULT UND
_Unwind_GetRegionStart@GCC_3.0 (36)
977: 00000000 0 FUNC GLOBAL DEFAULT UND
_Unwind_GetTextRelBase@GCC_3.0 (36)
990: 00000000 0 FUNC GLOBAL DEFAULT UND
_Unwind_RaiseException@GCC_3.0 (36)
1308: 00000000 0 FUNC GLOBAL DEFAULT UND
_Unwind_Resume_or_Rethrow@GCC_3.3 (37)
2102: 00000000 0 FUNC GLOBAL DEFAULT UND
_Unwind_GetLanguageSpecificData@GCC_3.0 (36)
2265: 00000000 0 FUNC GLOBAL DEFAULT UND _Unwind_VRS_Get@GCC_3.5
(35)
3328: 00000000 0 FUNC GLOBAL DEFAULT UND _Unwind_Complete@GCC_3.5
(35)
3810: 00000000 0 FUNC GLOBAL DEFAULT UND
_Unwind_GetDataRelBase@GCC_3.0 (36)
4594: 00000000 0 FUNC GLOBAL DEFAULT UND _Unwind_VRS_Set@GCC_3.5
(35)
4893: 00000000 0 FUNC GLOBAL DEFAULT UND
_Unwind_DeleteException@GCC_3.0 (36)
5076: 00000000 0 FUNC GLOBAL DEFAULT UND _Unwind_Resume@GCC_3.0
(36)
4923: 0006e11c 116 FUNC LOCAL DEFAULT 11
_ZL21base_of_encoded_valuehP15_Unwind_Context
4926: 0006e190 224 FUNC LOCAL DEFAULT 11
_ZL17parse_lsda_headerP15_Unwind_ContextPKhP16lsda_header_info
4934: 0006e990 104 FUNC LOCAL DEFAULT 11
_ZL33__gxx_dependent_exception_cleanup19_Unwind_Reason_CodeP21_Unwind_Control_Block
4995: 0006ee4c 84 FUNC LOCAL DEFAULT 11
_ZL22free_any_cxa_exceptionP21_Unwind_Control_Block
5001: 0006f00c 96 FUNC LOCAL DEFAULT 11
_ZL23__gxx_exception_cleanup19_Unwind_Reason_CodeP21_Unwind_Control_Block
13579: 00000000 0 FUNC GLOBAL DEFAULT UND _Unwind_GetRegionStart@
@GCC_3.0
13691: 00000000 0 FUNC GLOBAL DEFAULT UND _Unwind_GetTextRelBase@
@GCC_3.0
13704: 00000000 0 FUNC GLOBAL DEFAULT UND _Unwind_RaiseException@
@GCC_3.0
14022: 00000000 0 FUNC GLOBAL DEFAULT UND
_Unwind_Resume_or_Rethrow@@GCC_3.3
14816: 00000000 0 FUNC GLOBAL DEFAULT UND
_Unwind_GetLanguageSpecificData@@GCC_3.0
14979: 00000000 0 FUNC GLOBAL DEFAULT UND _Unwind_VRS_Get@@GCC_3.5
16042: 00000000 0 FUNC GLOBAL DEFAULT UND _Unwind_Complete@@GCC_3.5
16524: 00000000 0 FUNC GLOBAL DEFAULT UND _Unwind_GetDataRelBase@
@GCC_3.0
17308: 00000000 0 FUNC GLOBAL DEFAULT UND _Unwind_VRS_Set@@GCC_3.5
17607: 00000000 0 FUNC GLOBAL DEFAULT UND _Unwind_DeleteException@
@GCC_3.0
17790: 00000000 0 FUNC GLOBAL DEFAULT UND _Unwind_Resume@@GCC_3.0
> > readelf -aW /lib/libgcc_s.so.1 |grep Unwin
>
Result
------------
0002c1f0 0003a015 R_ARM_GLOB_DAT 00000000 __gnu_Unwind_Find_exidx
0002c108 00003016 R_ARM_JUMP_SLOT 0001b374 _Unwind_GetDataRelBase
0002c118 00007816 R_ARM_JUMP_SLOT 0001a2fc _Unwind_VRS_Set
0002c128 00012e16 R_ARM_JUMP_SLOT 0001b350
_Unwind_GetLanguageSpecificData
0002c154 00028316 R_ARM_JUMP_SLOT 0001a900 _Unwind_VRS_Pop
0002c178 00035e16 R_ARM_JUMP_SLOT 0001b340 _Unwind_GetRegionStart
0002c17c 00038116 R_ARM_JUMP_SLOT 0001b36c _Unwind_GetTextRelBase
0002c180 0003a016 R_ARM_JUMP_SLOT 00000000 __gnu_Unwind_Find_exidx
0002c198 00042616 R_ARM_JUMP_SLOT 0001a274 _Unwind_VRS_Get
Unwind table index '.ARM.exidx' at offset 0x1bd38 contains 34 entries:
0x19f00 <_Unwind_decode_typeinfo_ptr.isra.0>: 0x1 [cantunwind]
0x1a0f0 <_Unwind_GetCFA>: 0x1 [cantunwind]
0x1a0f8 <__gnu_Unwind_RaiseException>: 0x80383fab
0x1a1a0 <__gnu_Unwind_ForcedUnwind>: 0x1 [cantunwind]
0x1a1c4 <__gnu_Unwind_Resume>: 0x80aab0b0
0x1a238 <__gnu_Unwind_Resume_or_Rethrow>: 0x1 [cantunwind]
0x1a2d0 <_Unwind_GetGR>: 0x80048400
0x1a2fc <_Unwind_VRS_Set>: 0x1 [cantunwind]
0x1a358 <_Unwind_SetGR>: 0x80048400
0x1a384 <__gnu_Unwind_Backtrace>: 0x80b20dac
0x1a900 <_Unwind_VRS_Pop>: 0x80033fac
0x1aed4 <_Unwind_GetGR.constprop.1>: 0x80048400
0x1b340 <_Unwind_GetRegionStart>: 0x80a8b0b0
0x1b36c <_Unwind_GetTextRelBase.localalias.0>: 0x1 [cantunwind]
0x1b638 <_Unwind_SetGR>: 0x80048400
48: 0001b374 4 FUNC GLOBAL DEFAULT 10 _Unwind_GetDataRelBase@
@GCC_3.0
120: 0001a2fc 92 FUNC GLOBAL DEFAULT 10 _Unwind_VRS_Set@@GCC_3.5
302: 0001b350 28 FUNC GLOBAL DEFAULT 10
_Unwind_GetLanguageSpecificData@@GCC_3.0
352: 0001a258 4 FUNC GLOBAL DEFAULT 10 _Unwind_Complete@@GCC_3.5
356: 0001a25c 24 FUNC GLOBAL DEFAULT 10 _Unwind_DeleteException@
@GCC_3.0
620: 0001ae04 36 FUNC GLOBAL DEFAULT 10
_Unwind_Resume_or_Rethrow@@GCC_3.3
643: 0001a900 968 FUNC GLOBAL DEFAULT 10 _Unwind_VRS_Pop@@GCC_3.5
719: 0001ae28 36 FUNC GLOBAL DEFAULT 10 _Unwind_ForcedUnwind@
@GCC_3.0
793: 0001adbc 36 FUNC GLOBAL DEFAULT 10 _Unwind_RaiseException@
@GCC_3.0
835: 0001ae4c 36 FUNC GLOBAL DEFAULT 10 _Unwind_Backtrace@
@GCC_4.3.0
862: 0001b340 16 FUNC GLOBAL DEFAULT 10 _Unwind_GetRegionStart@
@GCC_3.0
897: 0001b36c 8 FUNC GLOBAL DEFAULT 10 _Unwind_GetTextRelBase@
@GCC_3.0
915: 0001a0f0 8 FUNC GLOBAL DEFAULT 10 _Unwind_GetCFA@@GCC_3.3
928: 00000000 0 FUNC WEAK DEFAULT UND __gnu_Unwind_Find_exidx
1062: 0001a274 92 FUNC GLOBAL DEFAULT 10 _Unwind_VRS_Get@@GCC_3.5
1069: 0001ade0 36 FUNC GLOBAL DEFAULT 10 _Unwind_Resume@@GCC_3.0
1351: 00019f00 20 FUNC LOCAL DEFAULT 10
_Unwind_decode_typeinfo_ptr.isra.0
1353: 00019f1c 4 FUNC LOCAL DEFAULT 10 _Unwind_DebugHook
1356: 0001a2d0 44 FUNC LOCAL DEFAULT 10 _Unwind_GetGR
1357: 0001a358 44 FUNC LOCAL DEFAULT 10 _Unwind_SetGR
1365: 0001aed4 44 FUNC LOCAL DEFAULT 10 _Unwind_GetGR.constprop.1
1367: 0001b36c 8 FUNC LOCAL DEFAULT 10
_Unwind_GetTextRelBase.localalias.0
1376: 0001b638 44 FUNC LOCAL DEFAULT 10 _Unwind_SetGR
1377: 0001b664 44 FUNC LOCAL DEFAULT 10 _Unwind_GetGR.constprop.0
1421: 0001ad50 0 FUNC LOCAL DEFAULT 10 __gnu_Unwind_Save_WMMXD
1423: 0001a238 32 FUNC LOCAL DEFAULT 10
__gnu_Unwind_Resume_or_Rethrow
1427: 0001ae04 36 FUNC LOCAL DEFAULT 10
___Unwind_Resume_or_Rethrow
1429: 0001ace4 0 FUNC LOCAL DEFAULT 10 __gnu_Unwind_Save_VFP
1438: 0001acec 0 FUNC LOCAL DEFAULT 10
__gnu_Unwind_Restore_VFP_D
1440: 0001a0f8 168 FUNC LOCAL DEFAULT 10
__gnu_Unwind_RaiseException
1441: 0001acf4 0 FUNC LOCAL DEFAULT 10 __gnu_Unwind_Save_VFP_D
1501: 0001ae4c 36 FUNC LOCAL DEFAULT 10 ___Unwind_Backtrace
1508: 0001ad04 0 FUNC LOCAL DEFAULT 10
__gnu_Unwind_Save_VFP_D_16_to_31
1513: 0001acfc 0 FUNC LOCAL DEFAULT 10
__gnu_Unwind_Restore_VFP_D_16_to_31
1528: 0001ad0c 0 FUNC LOCAL DEFAULT 10
__gnu_Unwind_Restore_WMMXD
1533: 0001ad94 0 FUNC LOCAL DEFAULT 10
__gnu_Unwind_Restore_WMMXC
1539: 0001ae28 36 FUNC LOCAL DEFAULT 10 ___Unwind_ForcedUnwind
1547: 0001adbc 36 FUNC LOCAL DEFAULT 10 ___Unwind_RaiseException
1557: 0001a1a0 36 FUNC LOCAL DEFAULT 10 __gnu_Unwind_ForcedUnwind
1559: 0001ade0 36 FUNC LOCAL DEFAULT 10 ___Unwind_Resume
1569: 0001a1c4 116 FUNC LOCAL DEFAULT 10 __gnu_Unwind_Resume
1574: 0001ada8 0 FUNC LOCAL DEFAULT 10 __gnu_Unwind_Save_WMMXC
1589: 0001a384 200 FUNC LOCAL DEFAULT 10 __gnu_Unwind_Backtrace
1590: 0001acdc 0 FUNC LOCAL DEFAULT 10 __gnu_Unwind_Restore_VFP
1663: 0001b374 4 FUNC GLOBAL DEFAULT 10 _Unwind_GetDataRelBase
1735: 0001a2fc 92 FUNC GLOBAL DEFAULT 10 _Unwind_VRS_Set
1917: 0001b350 28 FUNC GLOBAL DEFAULT 10
_Unwind_GetLanguageSpecificData
1967: 0001a258 4 FUNC GLOBAL DEFAULT 10 _Unwind_Complete
1971: 0001a25c 24 FUNC GLOBAL DEFAULT 10 _Unwind_DeleteException
2235: 0001ae04 36 FUNC GLOBAL DEFAULT 10 _Unwind_Resume_or_Rethrow
2258: 0001a900 968 FUNC GLOBAL DEFAULT 10 _Unwind_VRS_Pop
2334: 0001ae28 36 FUNC GLOBAL DEFAULT 10 _Unwind_ForcedUnwind
2408: 0001adbc 36 FUNC GLOBAL DEFAULT 10 _Unwind_RaiseException
2450: 0001ae4c 36 FUNC GLOBAL DEFAULT 10 _Unwind_Backtrace
2477: 0001b340 16 FUNC GLOBAL DEFAULT 10 _Unwind_GetRegionStart
2512: 0001b36c 8 FUNC GLOBAL DEFAULT 10 _Unwind_GetTextRelBase
2530: 0001a0f0 8 FUNC GLOBAL DEFAULT 10 _Unwind_GetCFA
2543: 00000000 0 FUNC WEAK DEFAULT UND __gnu_Unwind_Find_exidx
2677: 0001a274 92 FUNC GLOBAL DEFAULT 10 _Unwind_VRS_Get
2684: 0001ade0 36 FUNC GLOBAL DEFAULT 10 _Unwind_Resume
Thanks,
[-- Attachment #2: Type: text/html, Size: 23193 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: MUSL issue while loading C++ lib
2016-01-21 19:05 ` N Jain
@ 2016-01-21 20:06 ` Szabolcs Nagy
2016-01-21 21:17 ` N Jain
0 siblings, 1 reply; 8+ messages in thread
From: Szabolcs Nagy @ 2016-01-21 20:06 UTC (permalink / raw)
To: N Jain; +Cc: musl
* N Jain <jain61@gmail.com> [2016-01-21 14:05:41 -0500]:
>
> Also searching online I saw some issues with versions for
> GLIBCXX but don't know how to confirm if this is not the problem with MUSL
> toolchain I generated.
>
symbol versioning can cause problems, but gcc-5
libstdc++ and libgcc_s should work
> > > echo 'int main(){}' |g++ -xc++ -
> >
>
> I am not sure where to issue this command ?
i meant you should create a minimal dynamic linked
binary with your toolchain and analyze that
> > > readelf -ld ./a.out
> >
>
> INTERP 0x000114 0x00010114 0x00010114 0x00016 0x00016 R 0x1
> [Requesting program interpreter: /lib/ld-musl-arm.so.1]
...
> Dynamic section at offset 0xc24 contains 26 entries:
> Tag Type Name/Value
> 0x00000001 (NEEDED) Shared library: [libstdc++.so.6]
> 0x00000001 (NEEDED) Shared library: [libgcc_s.so.1]
> 0x00000001 (NEEDED) Shared library: [libc.so]
ok
> > > strace /lib/ld-musl-*.so.1 ./a.out
> >
>
> I don't have strace capability in my toolchain.
>
i wanted to see what paths are opened by the musl linker
to make sure the right libgcc_s.so.1 is found
> > > readelf -d /lib/libstdc++.so.6
> >
> 0x00000001 (NEEDED) Shared library: [libc.so]
> 0x00000001 (NEEDED) Shared library: [libgcc_s.so.1]
> 0x0000000e (SONAME) Library soname: [libstdc++.so.6]
ok
> > > readelf -aW /lib/libstdc++.so.6 |grep Unwind
> >
> 00137330 00051c16 R_ARM_JUMP_SLOT 00000000
> _Unwind_Resume_or_Rethrow
> 00137510 00083616 R_ARM_JUMP_SLOT 00000000
> _Unwind_GetLanguageSpecificData
my readelf prints the @GCC_3.x version suffix here.
i'm not sure what's the difference
> 1308: 00000000 0 FUNC GLOBAL DEFAULT UND
> _Unwind_Resume_or_Rethrow@GCC_3.3 (37)
> 2102: 00000000 0 FUNC GLOBAL DEFAULT UND
> _Unwind_GetLanguageSpecificData@GCC_3.0 (36)
...
> 14022: 00000000 0 FUNC GLOBAL DEFAULT UND
> _Unwind_Resume_or_Rethrow@@GCC_3.3
> 14816: 00000000 0 FUNC GLOBAL DEFAULT UND
> _Unwind_GetLanguageSpecificData@@GCC_3.0
ok
> > > readelf -aW /lib/libgcc_s.so.1 |grep Unwin
> >
>
> 302: 0001b350 28 FUNC GLOBAL DEFAULT 10
> _Unwind_GetLanguageSpecificData@@GCC_3.0
> 620: 0001ae04 36 FUNC GLOBAL DEFAULT 10
> _Unwind_Resume_or_Rethrow@@GCC_3.3
ok (.dynsym has the symbols)
> 1917: 0001b350 28 FUNC GLOBAL DEFAULT 10
> _Unwind_GetLanguageSpecificData
> 2235: 0001ae04 36 FUNC GLOBAL DEFAULT 10 _Unwind_Resume_or_Rethrow
this looks ok too
i think the musl linker should be able to deal with this :P
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: MUSL issue while loading C++ lib
2016-01-21 20:06 ` Szabolcs Nagy
@ 2016-01-21 21:17 ` N Jain
2016-01-21 22:48 ` Szabolcs Nagy
0 siblings, 1 reply; 8+ messages in thread
From: N Jain @ 2016-01-21 21:17 UTC (permalink / raw)
To: musl, Szabolcs Nagy
[-- Attachment #1: Type: text/plain, Size: 519 bytes --]
>
>
> > this looks ok too
>
> > i think the musl linker should be able to deal with this :P
>
Do you mean linking using "g++" is not right way ? I am trying to find out
if I could use "ld" directly but not sure what options to use and how to
pass libs.
I am using below commands to compile and link
gcc -c a.c -o bin/a.o
g++ -c acpp.cpp -o bin/acpp.o
g++ bin/a.o bin/acpp.o -o a.elf
While reading about the difference between ld and g++ linking I found g++
uses ld itself.
Am I missing something ?
Thanks,
NJ
[-- Attachment #2: Type: text/html, Size: 1347 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: MUSL issue while loading C++ lib
2016-01-21 21:17 ` N Jain
@ 2016-01-21 22:48 ` Szabolcs Nagy
2016-01-27 19:04 ` N Jain
0 siblings, 1 reply; 8+ messages in thread
From: Szabolcs Nagy @ 2016-01-21 22:48 UTC (permalink / raw)
To: N Jain; +Cc: musl
* N Jain <jain61@gmail.com> [2016-01-21 16:17:36 -0500]:
> >
> > > i think the musl linker should be able to deal with this :P
> >
>
>
> Do you mean linking using "g++" is not right way ? I am trying to find out
i meant the musl dynamic linker that loads the .so at runtime,
not the static linker you used at compilation.
> if I could use "ld" directly but not sure what options to use and how to
> pass libs.
when in doubt use -v too see what options gcc passes to ld
> I am using below commands to compile and link
>
> gcc -c a.c -o bin/a.o
> g++ -c acpp.cpp -o bin/acpp.o
>
> g++ bin/a.o bin/acpp.o -o a.elf
>
> While reading about the difference between ld and g++ linking I found g++
> uses ld itself.
> Am I missing something ?
>
i dont think so
and i think the linked binary is fine
libstdc++.so.6 vs libgcc_s.so.1 has some issues
which makes the musl linker fail to find some symbols.
i can't help further, you will have to debug it,
i'd try to look at dso->strings with gdb and why the find_sym fails
or recompile musl with some dprintf added,
or try a known working toolchain and compare against it,
or wait for other ideas..
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: MUSL issue while loading C++ lib
2016-01-21 22:48 ` Szabolcs Nagy
@ 2016-01-27 19:04 ` N Jain
2016-01-27 20:08 ` Szabolcs Nagy
0 siblings, 1 reply; 8+ messages in thread
From: N Jain @ 2016-01-27 19:04 UTC (permalink / raw)
To: musl, Szabolcs Nagy
[-- Attachment #1: Type: text/plain, Size: 1667 bytes --]
Hi All,
I was debugging and trying to find the issue in MUSL during finding
"_Unwind_Resume_or_Rethrow" symbol.
I see that under find_sym function sysv_lookup(s,h,dso) function it is not
able to get above names which seems to be right as the offset in reloc
section of "libstdc++.so.6" is zero
Example table below -
Offset Info Type Sym.Value Sym.
Name
0013700c 00000516 R_ARM_JUMP_SLOT 000c8bc8
_ZNSt13basic_filebufIcSt11char_traitsIcEE19_M_terminate_outputEv (*Able to
lookup*)
*00137330 00051c16 R_ARM_JUMP_SLOT 00000000 _Unwind_Resume_or_Rethrow
(Failed)*
*00137510 00083616 R_ARM_JUMP_SLOT 00000000 _Unwind_GetLanguageSpe
(Failed)*
> > and i think the linked binary is fine
>
> > libstdc++.so.6 vs libgcc_s.so.1 has some issues
> > which makes the musl linker fail to find some symbols.
>
From above dump I can see if Sym.Value = 0x0 then the symbol lookup fails.
Can some one know how to solve above issue ?
Also I am not able to find the code if libstdc++.so.6 needs dynamic
section libgcc_s.so.1
then by the time MUSL loads libstdc++.so.6 above symbols should not have
Sym.Value = 0x0 ?
>
> > i can't help further, you will have to debug it,
> > i'd try to look at dso->strings with gdb and why the find_sym fails
> > or recompile musl with some dprintf added,
> > or try a known working toolchain and compare against it,
> > or wait for other ideas..
>
Any one know code where if library itself is dependent on other library
where is symbol relocation happening ?
I guess the issue is in that part of MUSL code ? Is there any MUSL patch to
resolve above issue ?
Thanks,
NJ
[-- Attachment #2: Type: text/html, Size: 2522 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: MUSL issue while loading C++ lib
2016-01-27 19:04 ` N Jain
@ 2016-01-27 20:08 ` Szabolcs Nagy
0 siblings, 0 replies; 8+ messages in thread
From: Szabolcs Nagy @ 2016-01-27 20:08 UTC (permalink / raw)
To: N Jain; +Cc: musl
* N Jain <jain61@gmail.com> [2016-01-27 14:04:59 -0500]:
> I was debugging and trying to find the issue in MUSL during finding
> "_Unwind_Resume_or_Rethrow" symbol.
> I see that under find_sym function sysv_lookup(s,h,dso) function it is not
> able to get above names which seems to be right as the offset in reloc
> section of "libstdc++.so.6" is zero
>
> Example table below -
>
> Offset Info Type Sym.Value Sym.
> Name
> 0013700c 00000516 R_ARM_JUMP_SLOT 000c8bc8
> _ZNSt13basic_filebufIcSt11char_traitsIcEE19_M_terminate_outputEv (*Able to
> lookup*)
> *00137330 00051c16 R_ARM_JUMP_SLOT 00000000 _Unwind_Resume_or_Rethrow
> (Failed)*
> *00137510 00083616 R_ARM_JUMP_SLOT 00000000 _Unwind_GetLanguageSpe
> (Failed)*
>
0 is ok as these are defined in libgcc_s not libstdc++
i'd try to compile and run (gcc foo.c -lgcc_s)
void _Unwind_Resume_or_Rethrow();
int main()
{
_Unwind_Resume_or_Rethrow();
}
(it would segfault at runtime but the point is to see
if the symbol lookup succeeds, if not, you can debug
this easier than libstdc++, if yes, then compare
and see what's different)
> > > i can't help further, you will have to debug it,
> > > i'd try to look at dso->strings with gdb and why the find_sym fails
> > > or recompile musl with some dprintf added,
> > > or try a known working toolchain and compare against it,
> > > or wait for other ideas..
> >
>
> Any one know code where if library itself is dependent on other library
> where is symbol relocation happening ?
> I guess the issue is in that part of MUSL code ? Is there any MUSL patch to
> resolve above issue ?
the code is in ldso/dynlink.c
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2016-01-27 20:08 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-01-21 16:21 MUSL issue while loading C++ lib N Jain
2016-01-21 17:12 ` Szabolcs Nagy
2016-01-21 19:05 ` N Jain
2016-01-21 20:06 ` Szabolcs Nagy
2016-01-21 21:17 ` N Jain
2016-01-21 22:48 ` Szabolcs Nagy
2016-01-27 19:04 ` N Jain
2016-01-27 20:08 ` Szabolcs Nagy
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).