[llvm-dev] Targeting old glibc
Alexandre Bique via llvm-dev
llvm-dev at lists.llvm.org
Sun Nov 15 03:09:20 PST 2020
I'm following up with libc-help:
https://sourceware.org/pipermail/libc-help/2020-November/005555.html
Alexandre Bique
On Thu, Nov 12, 2020 at 11:01 AM Alexandre Bique
<bique.alexandre at gmail.com> wrote:
>
> On Wed, Nov 11, 2020 at 10:37 PM Fāng-ruì Sòng <maskray at google.com> wrote:
> > If you want to drop symbol versioning with llvm-objcopy:
> >
> > * llvm-objcopy -R .gnu.version -R .gnu.version_r in.so out.so
> > * However, llvm-objcopy zeroes out the section content so at runtime glibc ld.so will error
> > "unsupported version 0 of Verneed record".
> > Thus we need to drop the DT_VERNEED tag as well.
> > To achieve this, we can rewrite the DT_VERNEED tag to DT_NULL (0), terminating
> > the dynamic table, effectively deleting all DT_VER* tags. DT_RELACOUNT is also
> > deleted. Fortunately its absence does not affect correctness.
> > This requires binary patching
> >
> > ...
> > 0x000000006ffffffb (FLAGS_1) Flags: NOW
> > - 0x000000006ffffffe (VERNEED) 0x8ef0
> > - 0x000000006fffffff (VERNEEDNUM) 5
> > - 0x000000006ffffff0 (VERSYM) 0x89c0
> > - 0x000000006ffffff9 (RELACOUNT) 1536
> > 0x0000000000000000 (NULL) 0x0
> >
> >
> > In the end, the solution is:
> >
> > r2 -wqc '/x feffff6f00000000 @ section..dynamic; w0 16 @ hit0_0' a.so; llvm-objcopy -R .gnu.version -R .gnu.version_r a.so
>
> Thank you very much for your help.
>
> If I run:
> r2 -wqc '/x feffff6f00000000 @ section..dynamic; w0 16 @ hit0_0' a.so
> It results in a plugin that does not load anymore because: undefined
> symbol __at_exit, version
>
> Then if I continue with llvm-objcopy -R .gnu.version -R .gnu.version_r
> a.so; then the plugins can be dlopen() but when used something goes
> wrong and the plugin aborts.
>
> I'm not certain about continuing in this direction because it is
> getting very involved and if anything goes wrong difficult to support.
>
> Thank you so much Fāng-ruì Sòng for all your help and patience.
>
> Best regards,
> Alexandre BIQUE
More information about the llvm-dev
mailing list