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

[Tobias Hieta via llvm-dev]

Hello Peter,

I was able to fix this issue with this simple patch against llvm-objcopy:

diff --git a/llvm/tools/llvm-objcopy/ELF/ELFObjcopy.cpp
b/llvm/tools/llvm-objcopy/ELF/ELFObjcopy.cpp
index dd6a7d7e14b..c0dfd3a9838 100644
--- a/llvm/tools/llvm-objcopy/ELF/ELFObjcopy.cpp
+++ b/llvm/tools/llvm-objcopy/ELF/ELFObjcopy.cpp
@@ -503,6 +503,8 @@ static Error replaceAndRemoveSections(const
CopyConfig &Config, Object &Obj) {
return false;
if (StringRef(Sec.Name).startswith(".gnu.warning"))
return false;
+ if (StringRef(Sec.Name).startswith(".ARM.attributes"))
+ return false;
if (Sec.ParentSegment != nullptr)
return false;
return (Sec.Flags & SHF_ALLOC) == 0;

Is this a good way of fixing the issue? Happy to read up on how to
submit patches if you think this is the way to go.

-- Tobias


On Thu, Oct 17, 2019 at 12:27 PM Peter Smith <peter.smith at linaro.org> wrote:
>
> It is possible that it was present in older versions of glibc, with
> the limited time I've got for archaeology I found
> https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1712938
> My change in LLD was https://reviews.llvm.org/D27718 although it
> doesn't help much.
>
> You may be able to follow the bread crumb trail from the launchpad
> bug. Good luck!
>
> Peter
>
> On Thu, 17 Oct 2019 at 10:59, Tobias Hieta <tobias at plexapp.com> wrote:
> >
> > Peter,
> >
> > Thanks for your detailed response. I am not 100% sure on what libc we
> > are using here, it's a netgear NAS device. We publish Plex for
> > multiple NAS vendors devices and their toolchain always seems to lag
> > behind a bit, which is why we invested in building our own toolchain
> > based on LLVM tools.
> >
> > Does seem to be glibc though:
> > ii libc-bin 2.19-18+deb8u10.netgear1 armel GNU C Library: Binaries
> >
> > Maybe it's just because it's older why this happens?
> >
> > Thanks,
> > Tobias
> >
> > On Thu, Oct 17, 2019 at 11:25 AM Peter Smith <peter.smith at linaro.org> wrote:
> > >
> > > 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