Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160121200626.GD9621@port70.net>
Date: Thu, 21 Jan 2016 21:06:26 +0100
From: Szabolcs Nagy <nsz@...t70.net>
To: N Jain <jain61@...il.com>
Cc: musl@...ts.openwall.com
Subject: Re: MUSL issue while loading C++ lib

* N Jain <jain61@...il.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@..._3.3 (37)
>   2102: 00000000     0 FUNC    GLOBAL DEFAULT  UND
> _Unwind_GetLanguageSpecificData@..._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

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.