<div dir="ltr">Tobias,<div>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.</div><div><br></div><div>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.</div><div><br></div><div>Feel free to send a patch! (btw, my review handle is rupprecht, not rupprect).</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 17, 2019 at 5:29 AM Peter Smith via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello Tobias,<br>
<br>
I think that looks reasonable to me, I think it will be down to the<br>
llvm-objcopy team whether they want to make .ARM.attributes a special<br>
case or not. The best way to find out is to submit a patch, citing the<br>
problems with old versions of libc, I'd expect that you'll need to add<br>
a test case for the patch to be accepted. To do that it is probably<br>
best to look at the existing tests for llvm-strip and try and copy<br>
them. The test could be as simple as generating a binary with a<br>
section of type SHT_ARM_ATTRIBUTES and checking that strip didn't<br>
remove it. These tests sometimes use yaml2obj to generate an ELF file<br>
without needing a compiler and linker. Running the tests should be as<br>
simple as ninja check-llvm or make check-llvm depending on whether you<br>
used ninja or make when building llvm. If you want to run just one<br>
test then you can use bin/llvm-lit -v -a /path/to/test.s (from your<br>
build directory).<br>
<br>
The instructions on how to contribute are in<br>
<a href="https://llvm.org/docs/DeveloperPolicy.html" rel="noreferrer" target="_blank">https://llvm.org/docs/DeveloperPolicy.html</a> the people that I know have<br>
been active in llvm-objdump are MaskRay (Fangrui Song), rupprect<br>
(Jordan Rupprecht), grimar (George Rimar). If you include these people<br>
on the reviewers then I'm sure they'll be able to add anyone else that<br>
they think would be interested.<br>
<br>
Hope this helps<br>
<br>
Peter<br>
<br>
On Thu, 17 Oct 2019 at 12:53, Tobias Hieta <<a href="mailto:tobias@plexapp.com" target="_blank">tobias@plexapp.com</a>> wrote:<br>
><br>
> Hello Peter,<br>
><br>
> I was able to fix this issue with this simple patch against llvm-objcopy:<br>
><br>
> diff --git a/llvm/tools/llvm-objcopy/ELF/ELFObjcopy.cpp<br>
> b/llvm/tools/llvm-objcopy/ELF/ELFObjcopy.cpp<br>
> index dd6a7d7e14b..c0dfd3a9838 100644<br>
> --- a/llvm/tools/llvm-objcopy/ELF/ELFObjcopy.cpp<br>
> +++ b/llvm/tools/llvm-objcopy/ELF/ELFObjcopy.cpp<br>
> @@ -503,6 +503,8 @@ static Error replaceAndRemoveSections(const<br>
> CopyConfig &Config, Object &Obj) {<br>
> return false;<br>
> if (StringRef(Sec.Name).startswith(".gnu.warning"))<br>
> return false;<br>
> + if (StringRef(Sec.Name).startswith(".ARM.attributes"))<br>
> + return false;<br>
> if (Sec.ParentSegment != nullptr)<br>
> return false;<br>
> return (Sec.Flags & SHF_ALLOC) == 0;<br>
><br>
> Is this a good way of fixing the issue? Happy to read up on how to<br>
> submit patches if you think this is the way to go.<br>
><br>
> -- Tobias<br>
><br>
><br>
> On Thu, Oct 17, 2019 at 12:27 PM Peter Smith <<a href="mailto:peter.smith@linaro.org" target="_blank">peter.smith@linaro.org</a>> wrote:<br>
> ><br>
> > It is possible that it was present in older versions of glibc, with<br>
> > the limited time I've got for archaeology I found<br>
> > <a href="https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1712938" rel="noreferrer" target="_blank">https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1712938</a><br>
> > My change in LLD was <a href="https://reviews.llvm.org/D27718" rel="noreferrer" target="_blank">https://reviews.llvm.org/D27718</a> although it<br>
> > doesn't help much.<br>
> ><br>
> > You may be able to follow the bread crumb trail from the launchpad<br>
> > bug. Good luck!<br>
> ><br>
> > Peter<br>
> ><br>
> > On Thu, 17 Oct 2019 at 10:59, Tobias Hieta <<a href="mailto:tobias@plexapp.com" target="_blank">tobias@plexapp.com</a>> wrote:<br>
> > ><br>
> > > Peter,<br>
> > ><br>
> > > Thanks for your detailed response. I am not 100% sure on what libc we<br>
> > > are using here, it's a netgear NAS device. We publish Plex for<br>
> > > multiple NAS vendors devices and their toolchain always seems to lag<br>
> > > behind a bit, which is why we invested in building our own toolchain<br>
> > > based on LLVM tools.<br>
> > ><br>
> > > Does seem to be glibc though:<br>
> > > ii libc-bin 2.19-18+deb8u10.netgear1 armel GNU C Library: Binaries<br>
> > ><br>
> > > Maybe it's just because it's older why this happens?<br>
> > ><br>
> > > Thanks,<br>
> > > Tobias<br>
> > ><br>
> > > On Thu, Oct 17, 2019 at 11:25 AM Peter Smith <<a href="mailto:peter.smith@linaro.org" target="_blank">peter.smith@linaro.org</a>> wrote:<br>
> > > ><br>
> > > > Hello Tobias,<br>
> > > ><br>
> > > > Does your system happen to be using eglibc? I ran into this problem on<br>
> > > > an Ubuntu 14.04 system and it was down to the eglibc dynamic loader<br>
> > > > using the .ARM.attributes section when performing dlopen. Strictly<br>
> > > > speaking the .ARM.attributes section is only defined for relocatable<br>
> > > > objects, the ABI says that their presence in executables or dynamic<br>
> > > > loaders is neither required or forbidden, so it is somewhat risky for<br>
> > > > any portable program to depend on their presence.<br>
> > > ><br>
> > > > Since eglibc was merged back into glibc this dependency on<br>
> > > > .ARM.attributes went away. For LLD we took the position that it was<br>
> > > > worth keeping the .ARM.attributes to placate eglibc, as this was more<br>
> > > > likely to be encountered 2 years ago. I've not got a strong position<br>
> > > > on llvm-strip, in theory it should be strippable from executable and<br>
> > > > shared libraries, but there may be a case that eglibc is important<br>
> > > > enough to not strip by default.<br>
> > > ><br>
> > > > Peter<br>
> > > ><br>
> > > > On Thu, 17 Oct 2019 at 10:16, Tobias Hieta via llvm-dev<br>
> > > > <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
> > > > ><br>
> > > > > Hello Rui,<br>
> > > > ><br>
> > > > > Thanks for your reply. I tried with the keep-section argument and that<br>
> > > > > made the shared library work.<br>
> > > > ><br>
> > > > > Should these sections be kept around by default maybe?<br>
> > > > ><br>
> > > > > -- Tobias<br>
> > > > ><br>
> > > > > On Thu, Oct 17, 2019 at 11:06 AM Rui Ueyama <<a href="mailto:ruiu@google.com" target="_blank">ruiu@google.com</a>> wrote:<br>
> > > > > ><br>
> > > > > > 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?<br>
> > > > > ><br>
> > > > > > On Thu, Oct 17, 2019 at 5:37 PM Tobias Hieta via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
> > > > > >><br>
> > > > > >> Hello,<br>
> > > > > >><br>
> > > > > >> Recently we tried to streamline our toolchain by removing some GNU<br>
> > > > > >> tools with LLVM tools to avoid having multiple copies of strip, nm, ar<br>
> > > > > >> and similar tools. Today we ran into a really strange issue where<br>
> > > > > >> shared objects where not loadable.<br>
> > > > > >><br>
> > > > > >> We where able to track this down to llvm-strip with default arguments<br>
> > > > > >> creating a shared object that doesn't load correctly. It works if we<br>
> > > > > >> switch from not passing args to llvm-strip to pass -strip-all-gnu<br>
> > > > > >><br>
> > > > > >> I built bzip2 and libbz2.so to show this case here:<br>
> > > > > >> <a href="https://1drv.ms/u/s!Amjta5FRkBbbkiz14aHTRJe03LlL?e=2mGvTN" rel="noreferrer" target="_blank">https://1drv.ms/u/s!Amjta5FRkBbbkiz14aHTRJe03LlL?e=2mGvTN</a><br>
> > > > > >><br>
> > > > > >> This is the error we got by using the stripped shared object with<br>
> > > > > >> llvm-strip -strip-all:<br>
> > > > > >><br>
> > > > > >> admin@Netgear-RN212:~/b$ LD_PRELOAD=./libbz2.so.all ./bzip2<br>
> > > > > >> ERROR: ld.so: object './libbz2.so.all' from LD_PRELOAD cannot be<br>
> > > > > >> preloaded (cannot open shared object file): ignored.<br>
> > > > > >> ./bzip2: error while loading shared libraries: libbz2.so: cannot open<br>
> > > > > >> shared object file: No such file or directory<br>
> > > > > >><br>
> > > > > >> And with strip-all-gnu it works:<br>
> > > > > >> admin@Netgear-RN212:~/b$ LD_PRELOAD=./libbz2.so.all_gnu ./bzip2<br>
> > > > > >> bzip2: I won't write compressed data to a terminal.<br>
> > > > > >> bzip2: For help, type: `bzip2 --help'.<br>
> > > > > >><br>
> > > > > >> This only seems to happen on Linux-armv7hf - we haven't seen this on<br>
> > > > > >> any of the intel platforms.<br>
> > > > > >><br>
> > > > > >> Thanks,<br>
> > > > > >> Tobias<br>
> > > > > >> _______________________________________________<br>
> > > > > >> LLVM Developers mailing list<br>
> > > > > >> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
> > > > > >> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
> > > > > _______________________________________________<br>
> > > > > LLVM Developers mailing list<br>
> > > > > <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
> > > > > <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>