Bug 1546608
Summary: | ld does not merge .gnu.build.attributes | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | John Reiser <jreiser> |
Component: | binutils | Assignee: | Nick Clifton <nickc> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | low | Docs Contact: | |
Priority: | low | ||
Version: | 28 | CC: | aoliva, dvlasenk, jakub, nickc |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | binutils-2.31.1-17.fc29 | Doc Type: | If docs needed, set a value |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2019-02-02 03:34:43 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
John Reiser
2018-02-19 01:59:57 UTC
Hi John, The notes can be merged by the objcopy program. It has a special option: --merge-notes to do exactly this. The ability was not put into the linker in order to keep things simple - ie less chance of introducing bugs. It also means that older versions of the linker can still correctly process files containing the annobin notes. Cheers Nick Is objdump --merge-notes invoked during rpm post-processing? (In reply to Jakub Jelinek from comment #2) > Is objdump --merge-notes invoked during rpm post-processing? I do not think so. Maybe it should be, but I think that there are enough new things in the build process at the moment, so leaving it out (for now) is not such a bad thing. Note - the annobin notes are in a non-loadable section, so they do not take up space in the run-time image, only the on-disk image. Cheers Nick Hi John, (In reply to John Reiser from comment #0) > Also, the static binder "ld" is the program that handles alignment, and is > the only program that knows when two address ranges become contiguous > because of alignment. For example (reported by "readelf --wide --notes"): > GA$<tool>gcc 8.0.1 20180131 0x00000000 OPEN Applies to > region from 0x10580 to 0x1178a > GA$<tool>gcc 8.0.1 20180131 0x00000000 OPEN Applies to > region from 0x11790 to 0x119a9 > No program other than ld knows that the range from 0x1178a to 0x11790 has > been "bridged" by alignment. This means that all the annobin checkers > (built-by.sh, check-abi.sh, etc.) are working with incomplete information: > the range 0x1178a to 0x11790 could be occupied by code that was not produced > by gcc 8.0.1 20180131. Seriously ? You are worried about the case where 6 bytes of unannotated code might have been included in an executable's code space ? Theoretically possible true, but is it really worth worrying about ? Currently readelf will detect and warn about gaps of 16-bytes or larger in the code coverage of annobin notes. I could reduce that, but in order to prevent false positives when there is a real linker-inserted alignment adjustment, the code would then have to check to see if there were any symbols in the adjustment area. Which would make readelf slower and would not help if the unannotated code did not contain any symbols. I should also note that I am also working on an enhancement to the assembler, such that any time it creates an object file which does not contain any annobin notes, it automatically adds a note of its own, saying basically: "this unannotated region came from assembler input 'foo'". It may also include the assembler command line options as well. I am ot sure if that is needed or not at the moment. Cheers Nick Hi Nick, (In reply to Nick Clifton from comment #4) > Seriously ? You are worried about the case where 6 bytes of unannotated > code might have been included in an executable's code space ? Theoretically > possible, but is it really worth worrying about ? 6 to 15 bytes is enough to allow damage, particularly when there is such a region adjacent to the code for most compilation units. Here's an idea: When ld generates bytes because of alignment, then ld could extend the previous region in .gnu.build.attributes so as to cover those bytes (as long as the new bytes are the only extra bytes.) That allows making any subsequent adjacency/contiguity checking stronger. It does "paper over the alignment holes", although this is controlled by the designation of filler bytes in the [usually defaulted] linker script. This bug appears to have been reported against 'rawhide' during the Fedora 28 development cycle. Changing version to '28'. binutils-2.31.1-17.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2019-ba3cbcfd20 binutils-2.31.1-17.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-ba3cbcfd20 binutils-2.31.1-17.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report. |