aboutsummaryrefslogtreecommitdiff
path: root/libiberty/simple-object-common.h
diff options
context:
space:
mode:
authorJan Beulich <jbeulich@suse.com>2020-08-21 10:28:35 +0200
committerJan Beulich <jbeulich@suse.com>2020-08-21 10:28:35 +0200
commit610ed3e08f13b3886fd7194fb7a248dee8724685 (patch)
treef72f21054bc5b20cade2d9ebea3e3a1ca6eb318b /libiberty/simple-object-common.h
parent9cc9699833ccf94634b247da10a31c2ed60a9aad (diff)
downloadbinutils-610ed3e08f13b3886fd7194fb7a248dee8724685.zip
binutils-610ed3e08f13b3886fd7194fb7a248dee8724685.tar.gz
binutils-610ed3e08f13b3886fd7194fb7a248dee8724685.tar.bz2
fix objcopy of PE images with .buildid section
Xen Project embeds a build ID in its hypervisor binary (including its EFI variant), living in a standalone section. This usually gets placed right after .rodata, and due to the rounding done on the (file) size of .rodata the two sections appear to overlap (as far as e.g. find_section_by_vma() is concerned). With the first byte "found" in .rodata, nothing guarantees that the entire debug dir fits in that section, leading to apparently random failure of objcopy on such an image. Possible alternatives to the solution chosen: - make find_section_by_vma() honor virt_size, - correct the recording of sizes elsewhere (ibfd has size == virt_size, while obfd doesn't), - fix the linker to avoid producing apparently overlapping sections. While touching the condition around and the contents of the disgnostic, pull it up ahead of the bfd_malloc_and_get_section() call: There's no point first obtaining the section contents, in order to then fail.
Diffstat (limited to 'libiberty/simple-object-common.h')
0 files changed, 0 insertions, 0 deletions