|
Task Description
Attached to Project: Archlinux32
Opened by Jeff Hodd - 11.07.2019
Last edited by Andreas Baumann - 09.08.2019
FS#82 - [glibc] ld warning: /usr/lib32/ld-linux.so.2: corrupt GNU_PROPERTY_TYPE (5) size: 0
All software builds are producing this warning. Some builds are failing because of the error return on linking. I’m also seeing failures on LD_PRELOADs.
/bin/ld: warning: /usr/lib/ld-linux.so.2: corrupt GNU_PROPERTY_TYPE (5) size: 0
Easy to reproduce. Just build this program:
# test.c
# Compiled with ‘gcc test.c’ int main() {
return 0;
}
This was reported at bugs.archlinux.org (reference https://bugs.archlinux.org/task/63015) where it was closed and considered fixed if built using the –enable-cet flag. I built glibc with the –enable-cet flag, but am still seeing the failures, so not fixed.
Closed by Andreas Baumann
09.08.2019 11:44
Reason for closing: Fixed
Comments (6)
Related Tasks (0/0)
Jeff Hodd commented on 16.07.2019 03:29
I’ve narrowed down the glibc upgrade to glibc-2.29-1.26 -> glibc-2.29-1.27. The error doesn’t occur with glibc-2.29-1.26. There were 3 changes made to the arch32 PKGBUILD for the glibc-2.29-1.27 release. One of them caused this issue.
Admin
Andreas Baumann commented on 16.07.2019 05:33
There is another thing which can change: the toolchain.
This GNU_PROPERTY error is something the compiler emits (we think it’s CET stuff, but it’s badly
documented). Binutils ld seems not to like this ELF section.
The error is the same as in:
https://bugs.archlinux.org/task/63015
What’s puzzling me: –enable-cet is there in glibc, gcc, binutils (just not for i486, as CET doesn’t\
work for older CPUs).
Commit: 09d03cbd4c57b8eabfadd22b67929d958b2409d7 and d57a456faa674c24e8869a26a14c497c95accf1f in
glibc are mine, they try to change stack alignment and handling of SSE for pentium4 for Java, also without effect.
Admin
Andreas Baumann commented on 16.07.2019 05:35
About linker warnings being turned to errors (as for compiler warnings turned to errors): this
is something the DEVELOPER should do, NOT the PACKAGER. Released software should:
- NOT include asserts
- NOT include debug code
- NOT include code only used for running tests
- NOT use -Werror
- NOT use -Wl,–fatal-warnings
See for instance extra-cmake-modules-5.59.0-ld-no-fatal-warning.patch.
Jeff Hodd commented on 16.07.2019 21:50
I knew about the cet issue. Did quite abit of looking around to get some insight into it (even looked at the code - elf-properties.c - and it looks like the Elf_Internal_Note description size is coming back with a value of 0. the other possibility is that (size % 4) is something other than 0 which is less likely). From what i could gather, cet is supposed to be enabled in the latest builds of glibc for i686 even though, as you pointed out, it’s not well documented. I did do a 2.29-4 i686 build with cet enabled and it made no difference vis-a-vis the warning. I also checked the upstream diff between 2.29-1.26 and 2.29-1.27 and noticed the addition of –enable-static-pie and thought maybe position independent executables may explain it. Did another glibc build with static pie disabled and that made no difference. Am about to go back and check the diff again and see what else may have changed.
I did check the CMakeLists.txt file for my failing build and it uses -Werror and -Wl,–fatal-warnings so I will remove those. But that doesn;t actually fix the underlying issue of the warning which we shouldn;t be seeing.
It is up to the developer, but too often one has to show that a change fixes an issue before you’ll get any attention. I may not be THE developer for this particular package, but I am A developer (in general), so I don;t feel uncomfortable making code changes.
I’ll keep looking around for differences between the 1.26 and 1.27 builds.
Jeff Hodd commented on 16.07.2019 22:15
if (note->descsz < 8 || (note->descsz % align_size) != 0)
{
bad_size:
_bfd_error_handler
(_("warning: %pB: corrupt GNU_PROPERTY_TYPE (%ld) size: %#lx"),
abfd, note->type, note->descsz);
return FALSE;
}
The warning is printing out the description size - and that’s 0.
Apparently it’s supposed to be >= 8 and divisible by 4:
unsigned int align_size = bed->s->elfclass == ELFCLASS64 ? 8 : 4;
I am assuming that arch32 doesn’t support ELFCLASS64.
Jeff Hodd commented on 22.07.2019 17:13
https://bbs.archlinux32.org/viewtopic.php?id=2770
Google Cache
|
