(Received from Robert "ashes" on IRC - had some issues with getting to work with BugZilla) The following build failure occurs on binutils-2.21.1: cc1: warnings being treated as errors ../../bfd/elf.c: In function 'bfd_section_from_phdr': ../../bfd/elf.c:2482:7: error: passing argument 3 of '_bfd_elf_make_section_from_phdr' makes integer from pointer without a cast ../../bfd/elf.c:2348:1: note: expected 'int' but argument is of type 'char * (*)(const char *, int)' make[4]: *** [elf.lo] Error 1 This is caused by the third field in the call, which should be hdr_index instead of index. An updated pt_pax patch will be attached Reproducible: Always 19:55 < ashes> + return _bfd_elf_make_section_from_phdr (abfd, hdr, index, "pax_flags"); 19:55 < ashes> should be: 19:55 < ashes> + return _bfd_elf_make_section_from_phdr (abfd, hdr, hdr_index, "pax_flags"); 19:56 < ashes> the third field in the patch "index" should be "hdr_index" 19:56 < ashes> check the latest binutils 19:56 < ashes> the patch created fuzz, which was ignored 19:56 < ashes> the index macro has changed to hdr_index 19:57 < ashes> check the fuzz against the source 19:59 < ashes> i noticed this in 2.21.1 20:01 < ashes> http://www.linuxfromscratch.org/patches/downloads/binutils/binutils-2.21.1-pt_pax-1.patch 20:02 < ashes> that is the new patch 20:02 < ashes> this is not an issue of fuzz. this is an issue of the wrong argument being used 20:03 < ashes> i don't know the serverity of this bug 20:04 < ashes> i fixed it for my users, and i'm trying to report it uptream
Created attachment 283471 [details, diff] Updated pt_pax patch
Created attachment 283507 [details] build.log ~line 1992 libtool: compile: x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I/var/tmp/portage/sys-devel/binutils-2.21.1/work/binutils-2.21.1/bfd -I. -I/var/tmp/portage/sys-devel/binutils-2.21.1/work/binutils-2.21.1/bfd -I/var/tmp/portage/sys-devel/binutils-2.21.1/work/binutils-2.21.1/bfd/../include -DHAVE_bfd_elf64_x86_64_vec -DHAVE_bfd_elf32_i386_vec -DHAVE_i386linux_vec -DHAVE_i386pei_vec -DHAVE_x86_64pei_vec -DHAVE_bfd_elf64_l1om_vec -DHAVE_bfd_elf64_little_generic_vec -DHAVE_bfd_elf64_big_generic_vec -DHAVE_bfd_elf32_little_generic_vec -DHAVE_bfd_elf32_big_generic_vec -DHAVE_plugin_vec -DBINDIR=\"/usr/x86_64-pc-linux-gnu/binutils-bin/2.21.1\" -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -O2 -pipe -march=core2 -MT elf-ifunc.lo -MD -MP -MF .deps/elf-ifunc.Tpo -c /var/tmp/portage/sys-devel/binutils-2.21.1/work/binutils-2.21.1/bfd/elf-ifunc.c -o elf-ifunc.o >/dev/null 2>&1 /var/tmp/portage/sys-devel/binutils-2.21.1/work/binutils-2.21.1/bfd/elf.c: In function ‘bfd_section_from_phdr’: /var/tmp/portage/sys-devel/binutils-2.21.1/work/binutils-2.21.1/bfd/elf.c:2482:7: warning: passing argument 3 of ‘_bfd_elf_make_section_from_phdr’ makes integer from pointer without a cast /var/tmp/portage/sys-devel/binutils-2.21.1/work/binutils-2.21.1/bfd/elf.c:2348:1: note: expected ‘int’ but argument is of type ‘char * (*)(const char *, int)’ libtool: compile: x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I/var/tmp/portage/sys-devel/binutils-2.21.1/work/binutils-2.21.1/bfd -I. -I/var/tmp/portage/sys-devel/binutils-2.21.1/work/binutils-2.21.1/bfd -I/var/tmp/portage/sys-devel/binutils-2.21.1/work/binutils-2.21.1/bfd/../include -DHAVE_bfd_elf64_x86_64_vec -DHAVE_bfd_elf32_i386_vec -DHAVE_i386linux_vec -DHAVE_i386pei_vec -DHAVE_x86_64pei_vec -DHAVE_bfd_elf64_l1om_vec -DHAVE_bfd_elf64_little_generic_vec -DHAVE_bfd_elf64_big_generic_vec -DHAVE_bfd_elf32_little_generic_vec -DHAVE_bfd_elf32_big_generic_vec -DHAVE_plugin_vec -DBINDIR=\"/usr/x86_64-pc-linux-gnu/binutils-bin/2.21.1\" -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -O2 -pipe -march=core2 -MT elf-eh-frame.lo -MD -MP -MF .deps/elf-eh-frame.Tpo -c /var/tmp/portage/sys-devel/binutils-2.21.1/work/binutils-2.21.1/bfd/elf-eh-frame.c -fPIC -DPIC -o .libs/elf-eh-frame.o mv -f .deps/elf-ifunc.Tpo .deps/elf-ifunc.Plo --- It don't error out but the warning is there.
The error is from --enable-werror in Binutils. Look at the error, look at the patch, and look at the lines above the error. The third field "index" is wrong, and should be "hdr_index".
(In reply to comment #3) > The error is from --enable-werror in Binutils. Look at the error, look at the > patch, and look at the lines above the error. The third field "index" is wrong, > and should be "hdr_index". I'm pretty sure you're right. Reading bfd/elf.c, the function there is bfd_section_from_phdr which is basically one big switch-case on the phdr type. The parameter passed to this function is int hdr_index, and it is used in all the calls to _bfd_elf_make_section_from_phdr with the third parameter hdr_index. Except for case PT_PAX_FLAGS, where the third parameter is index. A quick search of the code shows that index not defined anywhere near that function. I'm cc-ing upstream to review this and make sure we're not missing something subtle. (And if we are, we'd better comment!)
has nothing to do with the werror configure flag. we've long been disabling it.
(In reply to comment #5) > has nothing to do with the werror configure flag. we've long been disabling > it. Nonetheless the fix is correct. If you take a look at binutils-2.20.1-r1, specifically at bfd/elf.c, you see that bfd_section_from_phdr reads: bfd_boolean bfd_section_from_phdr (bfd *abfd, Elf_Internal_Phdr *hdr, int index) { const struct elf_backend_data *bed; switch (hdr->p_type) { case PT_NULL: return _bfd_elf_make_section_from_phdr (abfd, hdr, index, "null"); case PT_LOAD: return _bfd_elf_make_section_from_phdr (abfd, hdr, index, "load"); ... etc ... The same snipet for binutils-2.21.1 reads bfd_boolean bfd_section_from_phdr (bfd *abfd, Elf_Internal_Phdr *hdr, int hdr_index) { const struct elf_backend_data *bed; switch (hdr->p_type) { case PT_NULL: return _bfd_elf_make_section_from_phdr (abfd, hdr, hdr_index, "null"); case PT_LOAD: return _bfd_elf_make_section_from_phdr (abfd, hdr, hdr_index, "load"); ... etc ... Upstream just renamed index -> hdr_index, but 63_all_binutils-2.21-pt-pax-flags-20101209.patch still uses index.
i didnt say the patch was incorrect, just that the reason for the ebuild failing is unknown. it shouldnt have. seems the behavior changed between 2.20.51.0.3 and 2.20.51.0.4, so ive fixed the patch in our patchset tree for all versions after 2.20.51.0.3. but ive only revbumped 2.21.1-r1 in the portage tree.
