Created attachment 1455550 [details] ifuncmod8.os $ ld -shared ifuncmod8.os ld: BFD version 2.29-13.fc27 internal error, aborting at elf64-x86-64.c:4354 in elf_x86_64_relocate_section This is with binutils-2.29-13.fc27.x86_64. With binutils-2.30-24.fc29.x86_64, the error is instead: ld: BFD version 2.30-24.fc29 internal error, aborting at elf64-x86-64.c:2427 in elf_x86_64_relocate_section I believe this is triggered by a recent annobin change. “readelf -n ifuncmod8.os” reports: readelf: ../build-x86_64-redhat-linux/elf/ifuncmod8.os: Warning: skipping unexpected symbol type IFUNC in section .rela.gnu.build.attributes relocation 2 It blocks rebuilding glibc in rawhide.
Hi Florian, This was caused by the recent change to the annobin plugin to use its own, hidden local symbols, rather than directly referencing specific function symbols. I was using the ".equiv" assembler directive to ensure that the annobin function start symbol had the same address as the real function start symbol. Unfortunately this also had the effect of copying the type of the function symbol. So if that function happened to be an ifunc, the annobin function symbol would also be an ifunc symbol. Since you cannot have relocations against local ifunc symbols, the linker complained. (Albeit in a not very helpful way). I have now changed the plugin so that it does not use the .equiv directive but instead just creates the annobin function start symbol at the start of the function and the annobin function end symbol at the end of the function. I have also taken the liberty of adding the source code of ifuncmod8.c to the annobin testsuite, just to make sure that this problem does not happen again. Please try annobin-8.2-1.fc28. Cheers Nick
Do you handle hot/cold partitioning too (then functions don't have a single start and end, but two starts and two ends).
Hi Jakub, > Do you handle hot/cold partitioning too (then functions don't have a single > start and end, but two starts and two ends). Oh bananas! No, I do not. :-( Is there an example of this that I can use for testing ? I thought that the hot/cold attributes just controlled whereabouts in memory an entire function would be placed. (And affecting branch predication). I did not know that it could result in split functions. Cheers Nick
gcc 8 and later at -O2 generates it a lot, but for a simple testcase use e.g. int bar (int); int baz (int) __attribute__((cold)); void foo (int x) { if (x) bar (bar (5)); else baz (baz (baz (baz (12)))); } at -O2.
Hi Jakub, Thanks - I can now generate the split function, and unfortunately the annobin plugin will not annotate the cold version. :-( I am now investigating how to fix this... Cheers Nick
Hi Jakub, I wonder if you can help me ? I am trying to find a reliable way for the annobin plugin to detect that a split cold function has been generated (and hence needs some annobin notes generated for it). I tried using varasm's cold_function_name decl, but this is not kept in sync with the current function. I also tried checking crtl->has_bb_partition but this is always zero. (At least at the points when the plugin checks. It currently uses the PLUGIN_ALL_PASSES_START and the PLUGIN_ALL_PASSES_END callbacks). I thought of checking the list of sections created by varasm, but this is static and so not available to the plugin. Do you have any suggestions ? Cheers Nick
I think that I have now found a way to detect cold sections. The latest annobin (annobin-8.12-1) has new code in it that works for the test case that I am using locally. I will leave this BZ open for now though, in case it turns out that I am being too optimistic...
This message is a reminder that Fedora 27 is nearing its end of life. On 2018-Nov-30 Fedora will stop maintaining and issuing updates for Fedora 27. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '27'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 27 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 27 changed to end-of-life (EOL) status on 2018-11-30. Fedora 27 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.