[llvm-dev] llvm-strip creates unloadable shared objects on linux-armv7hf

[Peter Smith via llvm-dev]

Hello Tobias,

Does your system happen to be using eglibc? I ran into this problem on
an Ubuntu 14.04 system and it was down to the eglibc dynamic loader
using the .ARM.attributes section when performing dlopen. Strictly
speaking the .ARM.attributes section is only defined for relocatable
objects, the ABI says that their presence in executables or dynamic
loaders is neither required or forbidden, so it is somewhat risky for
any portable program to depend on their presence.

Since eglibc was merged back into glibc this dependency on
.ARM.attributes went away. For LLD we took the position that it was
worth keeping the .ARM.attributes to placate eglibc, as this was more
likely to be encountered 2 years ago. I've not got a strong position
on llvm-strip, in theory it should be strippable from executable and
shared libraries, but there may be a case that eglibc is important
enough to not strip by default.

Peter

On Thu, 17 Oct 2019 at 10:16, Tobias Hieta via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>
> Hello Rui,
>
> Thanks for your reply. I tried with the keep-section argument and that
> made the shared library work.
>
> Should these sections be kept around by default maybe?
>
> -- Tobias
>
> On Thu, Oct 17, 2019 at 11:06 AM Rui Ueyama <ruiu at google.com> wrote:
> >
> > One thing I noticed is that llvm-strip seemed to remove a .ARM.attributes section. Can you try --keep-section=.ARM.attributes to tell to the command to keep the section?
> >
> > On Thu, Oct 17, 2019 at 5:37 PM Tobias Hieta via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> >>
> >> Hello,
> >>
> >> Recently we tried to streamline our toolchain by removing some GNU
> >> tools with LLVM tools to avoid having multiple copies of strip, nm, ar
> >> and similar tools. Today we ran into a really strange issue where
> >> shared objects where not loadable.
> >>
> >> We where able to track this down to llvm-strip with default arguments
> >> creating a shared object that doesn't load correctly. It works if we
> >> switch from not passing args to llvm-strip to pass -strip-all-gnu
> >>
> >> I built bzip2 and libbz2.so to show this case here:
> >> https://1drv.ms/u/s!Amjta5FRkBbbkiz14aHTRJe03LlL?e=2mGvTN
> >>
> >> This is the error we got by using the stripped shared object with
> >> llvm-strip -strip-all:
> >>
> >> admin at Netgear-RN212:~/b$ LD_PRELOAD=./libbz2.so.all ./bzip2
> >> ERROR: ld.so: object './libbz2.so.all' from LD_PRELOAD cannot be
> >> preloaded (cannot open shared object file): ignored.
> >> ./bzip2: error while loading shared libraries: libbz2.so: cannot open
> >> shared object file: No such file or directory
> >>
> >> And with strip-all-gnu it works:
> >> admin at Netgear-RN212:~/b$ LD_PRELOAD=./libbz2.so.all_gnu ./bzip2
> >> bzip2: I won't write compressed data to a terminal.
> >> bzip2: For help, type: `bzip2 --help'.
> >>
> >> This only seems to happen on Linux-armv7hf - we haven't seen this on
> >> any of the intel platforms.
> >>
> >> Thanks,
> >> Tobias
> >> _______________________________________________
> >> LLVM Developers mailing list
> >> llvm-dev at lists.llvm.org
> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev