[Bug gold/25617] New: Gold looks up shared object information in section headers instead of the dynamic array
https://sourceware.org/bugzilla/show_bug.cgi?id=25617 Bug ID: 25617 Summary: Gold looks up shared object information in section headers instead of the dynamic array Product: binutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: gold Assignee: ccoutant at gmail dot com Reporter: klkblake at gmail dot com CC: ian at airs dot com Target Milestone: --- For shared objects, all information needed for linking is in the dynamic array, and section headers are optional. However, gold looks up the information it needs in the (optional) section headers instead of the (mandatory) dynamic array, and fails if the section headers are not present. As a result, gold is unable to link to shared objects with no section headers, even though such shared objects are spec-compliant and the dynamic linker can load them without issue. This is unfortunate, as working around it requires redundantly respecifying most of the dynamic array in section headers. This seems like it should not be too hard to fix, from what I've seen of gold's shared object handling, but I'm not particularly familiar with the codebase so I don't know if there are things I'm missing. The BFD-based linker also exhibits this issue. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/25617] Gold looks up shared object information in section headers instead of the dynamic array
https://sourceware.org/bugzilla/show_bug.cgi?id=25617 --- Comment #2 from Kaylee --- Created attachment 12331 --> https://sourceware.org/bugzilla/attachment.cgi?id=12331&action=edit testcase with no section headers This test case has no section headers; gold immediately errors due to attempting to read the nonexistent header for `.shstrtab`. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/25617] Gold looks up shared object information in section headers instead of the dynamic array
https://sourceware.org/bugzilla/show_bug.cgi?id=25617 --- Comment #3 from Kaylee --- Created attachment 12332 --> https://sourceware.org/bugzilla/attachment.cgi?id=12332&action=edit testcase with only shstrtab This testcase has a minimal section header table containing only `.shstrtab`. This works around the previous error, but linking against it fails anyway as gold only tries to find `.dynsym` through the section header table. Both test cases expose a single function, `run()`, that does nothing but return. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/25617] Gold looks up shared object information in section headers instead of the dynamic array
https://sourceware.org/bugzilla/show_bug.cgi?id=25617 --- Comment #5 from Kaylee --- Created attachment 12336 --> https://sourceware.org/bugzilla/attachment.cgi?id=12336&action=edit patch to add flag to not emit section header tables I've written a small patch to add such a flag, does this look good to you? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/25617] Gold looks up shared object information in section headers instead of the dynamic array
https://sourceware.org/bugzilla/show_bug.cgi?id=25617 Kaylee changed: What|Removed |Added Attachment #12336|0 |1 is obsolete|| --- Comment #7 from Kaylee --- Created attachment 12340 --> https://sourceware.org/bugzilla/attachment.cgi?id=12340&action=edit patch to add flag to not emit section header tables Re-uploading with an email I'm less worried about getting scraped and spammed at. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/25617] Gold looks up shared object information in section headers instead of the dynamic array
https://sourceware.org/bugzilla/show_bug.cgi?id=25617 --- Comment #8 from Kaylee --- Created attachment 12341 --> https://sourceware.org/bugzilla/attachment.cgi?id=12341&action=edit patch to add a test for the flag This adds some testing for the flag. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/25617] Gold looks up shared object information in section headers instead of the dynamic array
https://sourceware.org/bugzilla/show_bug.cgi?id=25617 --- Comment #9 from Kaylee --- Created attachment 12342 --> https://sourceware.org/bugzilla/attachment.cgi?id=12342&action=edit patch to add BFD support for not emitting the section header table -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/25617] Gold looks up shared object information in section headers instead of the dynamic array
https://sourceware.org/bugzilla/show_bug.cgi?id=25617 --- Comment #10 from Kaylee --- Created attachment 12343 --> https://sourceware.org/bugzilla/attachment.cgi?id=12343&action=edit patch to add flag to not emit the section header table to the BFD-based ld I'll add a testcase shortly. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/25617] Gold looks up shared object information in section headers instead of the dynamic array
https://sourceware.org/bugzilla/show_bug.cgi?id=25617 --- Comment #14 from Kaylee --- The information on the number of symbols in the symbol table is available in DT_HASH->nchain, as the chain table parallels the symbol table. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/25617] Gold looks up shared object information in section headers instead of the dynamic array
https://sourceware.org/bugzilla/show_bug.cgi?id=25617 --- Comment #16 from Kaylee --- Created attachment 12348 --> https://sourceware.org/bugzilla/attachment.cgi?id=12348&action=edit patch to add test for -z nosectionheader This patch adds the test for it, based against your branch. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/25617] Gold looks up shared object information in section headers instead of the dynamic array
https://sourceware.org/bugzilla/show_bug.cgi?id=25617
--- Comment #18 from Kaylee ---
I get uninitialised variable usage errors when I try to build it, in this
section of elf_link_is_defined_archive_symbol():
> if (elf_bad_symtab (abfd))
> {
> extsymcount = symcount;
> extsymoff = 0;
> }
> else
> {
> extsymcount = symcount - hdr->sh_info;
> extsymoff = hdr->sh_info;
> }
Looks like symcount and hdr aren't initialized if extsymcount was nonzero in
the previous conditional?
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug gold/25617] Gold looks up shared object information in section headers instead of the dynamic array
https://sourceware.org/bugzilla/show_bug.cgi?id=25617 --- Comment #20 from Kaylee --- Works for me now! -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25617] ld should reconstruct dynamic symbol table from PT_DYNAMIC when there is no section header
https://sourceware.org/bugzilla/show_bug.cgi?id=25617 --- Comment #23 from Kaylee --- I got a failure in the ld testsuite in x86-64.exp. Unfortunately, about an hour later, my computer crashed, and I have since been unable to reproduce it. I think the text was something like "RELATIVE RELOCATION FAULT"?. It's possible that it was just some transient failure in my system that also lead to the crash. Using --remove-section-header on one of my test cases, objcopy issues a warning "Could not find any mergeable note sections". Probably it shouldn't warn about that unless --merge-notes was explicitly specified. Using objcopy (even without any flags) results in a shared object that segfaults at runtime. Looking at readelf output, it seems like objcopy is modifying the PT_LOAD entries. In particular, it seems to be moving the program header to the start of the file, and then modifying the PT_LOAD entry that covers the program header to cover it's new location, without taking into account that this makes two segments overlap, which is illegal. Though even if it modified it correctly, as a shared object its loaded segments may contain arbitrary cross-references from e.g. PC-relative relocations which were resolved at link time, and so can't be safely modified at all. strip has the same issues. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25617] ld should reconstruct dynamic symbol table from PT_DYNAMIC when there is no section header
https://sourceware.org/bugzilla/show_bug.cgi?id=25617 --- Comment #24 from Kaylee --- Apologies, with the new objcopy version it isn't generating overlapping PT_LOAD entries, though it is still modifying them and moving the program header. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25617] ld should reconstruct dynamic symbol table from PT_DYNAMIC when there is no section header
https://sourceware.org/bugzilla/show_bug.cgi?id=25617 --- Comment #27 from Kaylee --- Created attachment 12357 --> https://sourceware.org/bugzilla/attachment.cgi?id=12357&action=edit testcase for objcopy breakage This .so works fine, but if put through objcopy (even without flags), objcopy will attempt to copy the program header, and extend the relevant PT_LOAD entry to cover the new location. Unfortunately, it does not take into account that the endpoints of a loaded region are rounded up to page sizes, and as a result it will cause the first page of the second segment to overlap the last page of the first segment. I don't know if it's trying to create a second header because the .so -> BFD -> .so conversion is lossy, or if it's actively trying to modify it, but probably it should treat the program header as fixed, since application code may depend both on the specific values stored in it and also that the values are correct. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25617] ld should reconstruct dynamic symbol table from PT_DYNAMIC when there is no section header
https://sourceware.org/bugzilla/show_bug.cgi?id=25617 --- Comment #28 from Kaylee --- Created attachment 12358 --> https://sourceware.org/bugzilla/attachment.cgi?id=12358&action=edit test case for note warning This is a testcase for the warning about no note section. I think any shared library compiled by clang or gcc should trigger this warning. I would guess that it's just that --remove-section-header implies --merge-notes, and --merge-notes warns if there aren't any notes to merge because it assumes the user explicitly requested it? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25617] ld should reconstruct dynamic symbol table from PT_DYNAMIC when there is no section header
https://sourceware.org/bugzilla/show_bug.cgi?id=25617 --- Comment #31 from Kaylee --- Yep, I'm not getting the warning with the new version. Also the test case that I mentioned failed appears to be ld/testsuite/ld-x86-64/pr17618.d, which I think is probably unrelated. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25617] ld should reconstruct dynamic symbol table from PT_DYNAMIC when there is no section header
https://sourceware.org/bugzilla/show_bug.cgi?id=25617 --- Comment #38 from Kaylee --- > How can I reproduce it? Do they fail on master branch? Yeah, they fail on master for me. Additionally, I've just found out that ld segfaults when trying to link against a shared object with GNU_PROPERTY_NO_COPY_ON_PROTECTED and no section headers; am looking into it. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25617] ld should reconstruct dynamic symbol table from PT_DYNAMIC when there is no section header
https://sourceware.org/bugzilla/show_bug.cgi?id=25617 --- Comment #35 from Kaylee --- There are a couple of typos in the comments: "symbol stable", "string stable", and "memory chekers". -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25617] ld should reconstruct dynamic symbol table from PT_DYNAMIC when there is no section header
https://sourceware.org/bugzilla/show_bug.cgi?id=25617 --- Comment #39 from Kaylee --- Created attachment 12359 --> https://sourceware.org/bugzilla/attachment.cgi?id=12359&action=edit testcase for GNU_PROPERTY_NO_COPY_ON_PROTECTED segfault The attached file exports an `int foo`, linking against it will segfault ld. It seems like it is segfaulting because it's calling SYMBOL_NO_COPYRELOC(info, eh), which is doing checks on members of `(EH)->elf.root.u.def.section->owner`, but this is set to NULL. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25617] ld should reconstruct dynamic symbol table from PT_DYNAMIC when there is no section header
https://sourceware.org/bugzilla/show_bug.cgi?id=25617 --- Comment #34 from Kaylee --- I'm getting several failures: > FAIL: Build pr22393-2 (-z nosectionheader, none) > FAIL: Build pr22393-2 (PIE, -z nosectionheader, none) > FAIL: Build pr22393-2 (-z nosectionheader, objcopy) > FAIL: Build pr22393-2 (PIE, -z nosectionheader, objcopy) > FAIL: Build pr22393-2 (-z nosectionheader, strip) > FAIL: Build pr22393-2 (PIE, -z nosectionheader, strip) Looking at the logs, they all have this: > extra lines in dump.out starting with "^1000 T _init$" Also I've managed to get the log for the sporadic x86-64.exp failure I mentioned, and it's just failing to allocate the 2GB it needs because I don't happen to have that amount free, so that's nothing to worry about. -- You are receiving this mail because: You are on the CC list for the bug.
