[RFC PATCH] Avoid emitting TEXTREL marker for R_ARM_NONE relocs.
Wed Mar 12 17:17:00 GMT 2014
I have a case where ld -shared emitted the DT_TEXTREL marker but there were
no actual text relocs. It turns out that what it thought were going to be
text relocs were reloc slots that got turned into R_ARM_NONE in the final
I have a dim memory of someone explaining that emitting R_ARM_NONE dynamic
relocs was intractable to avoid in some cases. But I don't understand what
situations cause that to happen. Nor could I figure out today where in the
code it actually happens. So I am at something of a loss for coming up
with a concise test case for the bug that I encountered. Also for giving
an adequate explanation of the scenario in the comment I'm adding below.
It looks to me like this early setting of DF_TEXTREL was always redundant
with the scan done with elf32_arm_readonly_dynrelocs at the end. So I'm
fairly confident the change is correct, if possibly suboptimal. But I'd
like to understand enough to write a good test case and explain the fix
better in the comments.
2014-03-12 Roland McGrath <email@example.com>
* elf32-arm.c (elf32_arm_size_dynamic_sections): Don't set
DF_TEXTREL while setting up space for local dynamic relocs.
@@ -13766,8 +13766,13 @@ elf32_arm_size_dynamic_sections (bfd *
srel = elf_section_data (p->sec)->sreloc;
elf32_arm_allocate_dynrelocs (info, srel, p->count);
- if ((p->sec->output_section->flags & SEC_READONLY) != 0)
- info->flags |= DF_TEXTREL;
+ /* It would appear that we could check for the output
+ section being SEC_READONLY and set DF_TEXTREL here.
+ But these relocs might be morphed into R_ARM_NONE
+ later, making the test here false-positive.
+ Instead, we'll just let the scan at the end of the
+ function (using elf32_arm_readonly_dynrelocs) catch
+ any that survive. */
More information about the Binutils