llvm dev - Oct 2019 - llvm-strip creates unloadable shared objects on linux-armv7hf

Jordan,

I have sent the patch via Phabricator: https://reviews.llvm.org/D69188

Let me know if I got it right.

-- Tobias

On Thu, Oct 17, 2019 at 7:12 PM Jordan Rupprecht <rupprecht at google.com>
wrote:
>
> Tobias,
> I don't have much experience with ARM, but from your report and
Peter's explanation of why LLD does it, I agree we should be consistent with
LLD and keep the section.
>
> From my skimming of the LLD sources, it looks like we keep arm attributes
section based on the section type being SHT_ARM_ATTRIBUTES, not on the name
being ".ARM.attributes". Other than that, this change seems good to
accept.
>
> Feel free to send a patch! (btw, my review handle is rupprecht, not
rupprect).
>
> On Thu, Oct 17, 2019 at 5:29 AM Peter Smith via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
>>
>> Hello Tobias,
>>
>> I think that looks reasonable to me, I think it will be down to the
>> llvm-objcopy team whether they want to make .ARM.attributes a special
>> case or not. The best way to find out is to submit a patch, citing the
>> problems with old versions of libc, I'd expect that you'll need
to add
>> a test case for the patch to be accepted. To do that it is probably
>> best to look at the existing tests for llvm-strip and try and copy
>> them. The test could be as simple as generating a binary with a
>> section of type SHT_ARM_ATTRIBUTES and checking that strip didn't
>> remove it. These tests sometimes use yaml2obj to generate an ELF file
>> without needing a compiler and linker. Running the tests should be as
>> simple as ninja check-llvm or make check-llvm depending on whether you
>> used ninja or make when building llvm. If you want to run just one
>> test then you can use bin/llvm-lit -v -a /path/to/test.s (from your
>> build directory).
>>
>> The instructions on how to contribute are in
>> https://llvm.org/docs/DeveloperPolicy.html the people that I know have
>> been active in llvm-objdump are MaskRay (Fangrui Song), rupprect
>> (Jordan Rupprecht), grimar (George Rimar). If you include these people
>> on the reviewers then I'm sure they'll be able to add anyone
else that
>> they think would be interested.
>>
>> Hope this helps
>>
>> Peter
>>
>> On Thu, 17 Oct 2019 at 12:53, Tobias Hieta <tobias at
plexapp.com> wrote:
>> >
>> > 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
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

Everyone,

Just to close this loop, the patch was accepted into master today:
https://github.com/llvm/llvm-project/commit/fb4a55010ee9bd03720609c8542f770775576fc8

Thanks for everyone guiding me!

Tobias

On Fri, Oct 18, 2019 at 8:41 PM Tobias Hieta <tobias at plexapp.com>
wrote:
>
> Jordan,
>
> I have sent the patch via Phabricator: https://reviews.llvm.org/D69188
>
> Let me know if I got it right.
>
> -- Tobias
>
> On Thu, Oct 17, 2019 at 7:12 PM Jordan Rupprecht <rupprecht at
google.com> wrote:
> >
> > Tobias,
> > I don't have much experience with ARM, but from your report and
Peter's explanation of why LLD does it, I agree we should be consistent with
LLD and keep the section.
> >
> > From my skimming of the LLD sources, it looks like we keep arm
attributes section based on the section type being SHT_ARM_ATTRIBUTES, not on
the name being ".ARM.attributes". Other than that, this change seems
good to accept.
> >
> > Feel free to send a patch! (btw, my review handle is rupprecht, not
rupprect).
> >
> > On Thu, Oct 17, 2019 at 5:29 AM Peter Smith via llvm-dev <llvm-dev
at lists.llvm.org> wrote:
> >>
> >> Hello Tobias,
> >>
> >> I think that looks reasonable to me, I think it will be down to
the
> >> llvm-objcopy team whether they want to make .ARM.attributes a
special
> >> case or not. The best way to find out is to submit a patch, citing
the
> >> problems with old versions of libc, I'd expect that you'll
need to add
> >> a test case for the patch to be accepted. To do that it is
probably
> >> best to look at the existing tests for llvm-strip and try and copy
> >> them. The test could be as simple as generating a binary with a
> >> section of type SHT_ARM_ATTRIBUTES and checking that strip
didn't
> >> remove it. These tests sometimes use yaml2obj to generate an ELF
file
> >> without needing a compiler and linker. Running the tests should be
as
> >> simple as ninja check-llvm or make check-llvm depending on whether
you
> >> used ninja or make when building llvm. If you want to run just one
> >> test then you can use bin/llvm-lit -v -a /path/to/test.s (from
your
> >> build directory).
> >>
> >> The instructions on how to contribute are in
> >> https://llvm.org/docs/DeveloperPolicy.html the people that I know
have
> >> been active in llvm-objdump are MaskRay (Fangrui Song), rupprect
> >> (Jordan Rupprecht), grimar (George Rimar). If you include these
people
> >> on the reviewers then I'm sure they'll be able to add
anyone else that
> >> they think would be interested.
> >>
> >> Hope this helps
> >>
> >> Peter
> >>
> >> On Thu, 17 Oct 2019 at 12:53, Tobias Hieta <tobias at
plexapp.com> wrote:
> >> >
> >> > 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
> >> _______________________________________________
> >> LLVM Developers mailing list
> >> llvm-dev at lists.llvm.org
> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

Thanks for your contribution! I'm sure I can speak for all of us when I say
that we look forward to more contributions from you, if you see anything
else you'd like to work on.

James

On Thu, 31 Oct 2019 at 12:05, Tobias Hieta via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Everyone,
>
> Just to close this loop, the patch was accepted into master today:
>
>
https://github.com/llvm/llvm-project/commit/fb4a55010ee9bd03720609c8542f770775576fc8
>
> Thanks for everyone guiding me!
>
> Tobias
>
> On Fri, Oct 18, 2019 at 8:41 PM Tobias Hieta <tobias at plexapp.com>
wrote:
> >
> > Jordan,
> >
> > I have sent the patch via Phabricator: https://reviews.llvm.org/D69188
> >
> > Let me know if I got it right.
> >
> > -- Tobias
> >
> > On Thu, Oct 17, 2019 at 7:12 PM Jordan Rupprecht <rupprecht at
google.com>
> wrote:
> > >
> > > Tobias,
> > > I don't have much experience with ARM, but from your report
and
> Peter's explanation of why LLD does it, I agree we should be consistent
> with LLD and keep the section.
> > >
> > > From my skimming of the LLD sources, it looks like we keep arm
> attributes section based on the section type being SHT_ARM_ATTRIBUTES, not
> on the name being ".ARM.attributes". Other than that, this change
seems
> good to accept.
> > >
> > > Feel free to send a patch! (btw, my review handle is rupprecht,
not
> rupprect).
> > >
> > > On Thu, Oct 17, 2019 at 5:29 AM Peter Smith via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
> > >>
> > >> Hello Tobias,
> > >>
> > >> I think that looks reasonable to me, I think it will be down
to the
> > >> llvm-objcopy team whether they want to make .ARM.attributes a
special
> > >> case or not. The best way to find out is to submit a patch,
citing the
> > >> problems with old versions of libc, I'd expect that
you'll need to add
> > >> a test case for the patch to be accepted. To do that it is
probably
> > >> best to look at the existing tests for llvm-strip and try and
copy
> > >> them. The test could be as simple as generating a binary with
a
> > >> section of type SHT_ARM_ATTRIBUTES and checking that strip
didn't
> > >> remove it. These tests sometimes use yaml2obj to generate an
ELF file
> > >> without needing a compiler and linker. Running the tests
should be as
> > >> simple as ninja check-llvm or make check-llvm depending on
whether you
> > >> used ninja or make when building llvm. If you want to run
just one
> > >> test then you can use bin/llvm-lit -v -a /path/to/test.s
(from your
> > >> build directory).
> > >>
> > >> The instructions on how to contribute are in
> > >> https://llvm.org/docs/DeveloperPolicy.html the people that I
know
> have
> > >> been active in llvm-objdump are MaskRay (Fangrui Song),
rupprect
> > >> (Jordan Rupprecht), grimar (George Rimar). If you include
these people
> > >> on the reviewers then I'm sure they'll be able to add
anyone else that
> > >> they think would be interested.
> > >>
> > >> Hope this helps
> > >>
> > >> Peter
> > >>
> > >> On Thu, 17 Oct 2019 at 12:53, Tobias Hieta <tobias at
plexapp.com>
> wrote:
> > >> >
> > >> > 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
> > >> _______________________________________________
> > >> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20191031/36b12ecb/attachment.html>