From: David Poole <daveml@mbuf.com>
To: binutils@sources.redhat.com
Subject: Re: DT_TEXTREL/.dynamic issue with the binutils 2.15 linker on ARM and Linux
Date: Tue, 01 Jun 2004 16:59:00 -0000 [thread overview]
Message-ID: <FF30F76A-B3EC-11D8-93CF-000393CDE218@mbuf.com> (raw)
In-Reply-To: <20040529060633.GH3368@bubble.modra.org>
[-- Attachment #1: Type: text/plain, Size: 441 bytes --]
On May 29, 2004, at 12:06 AM, Alan Modra wrote:
> On Fri, May 28, 2004 at 10:56:09AM -0400, Daniel Jacobowitz wrote:
>> I don't know why DT_TEXTREL isn't there for this case. It should be.
>
> Perhaps because elf32-arm.h doesn't have something like
> readonly_dynrelocs as implemented in other backends.
Looking at elf32-i386.c and elf32-s390.c, I copied the
readonly_dynrelocs() and the call in
elf_(i386|s390)_size_dynamic_sections.
[-- Attachment #2: binutils-2.15-elf32-arm-textrel.patch --]
[-- Type: application/octet-stream, Size: 2009 bytes --]
diff -uNr binutils-2.15.orig/ binutils-2.15
diff -uNr binutils-2.15.orig/bfd/elf32-arm.h binutils-2.15/bfd/elf32-arm.h
--- binutils-2.15.orig/bfd/elf32-arm.h 2004-05-17 13:35:58.000000000 -0600
+++ binutils-2.15/bfd/elf32-arm.h 2004-06-01 10:44:52.000000000 -0600
@@ -87,6 +87,8 @@
#endif
static bfd_boolean allocate_dynrelocs
PARAMS ((struct elf_link_hash_entry *h, PTR inf));
+static bfd_boolean elf32_arm_readonly_dynrelocs
+ PARAMS ((struct elf_link_hash_entry *, PTR));
static bfd_boolean create_got_section
PARAMS ((bfd * dynobj, struct bfd_link_info * info));
static bfd_boolean elf32_arm_create_dynamic_sections
@@ -3457,6 +3459,37 @@
return TRUE;
}
+/* Find any dynamic relocs that apply to read-only sections. */
+
+static bfd_boolean
+elf32_arm_readonly_dynrelocs (h, inf)
+ struct elf_link_hash_entry *h;
+ PTR inf;
+{
+ struct elf32_arm_link_hash_entry *eh;
+ struct elf32_arm_relocs_copied *p;
+
+ if (h->root.type == bfd_link_hash_warning)
+ h = (struct elf_link_hash_entry *) h->root.u.i.link;
+
+ eh = (struct elf32_arm_link_hash_entry *) h;
+ for (p = eh->relocs_copied; p != NULL; p = p->next)
+ {
+ asection *s = p->section;
+
+ if (s != NULL && (s->flags & SEC_READONLY) != 0)
+ {
+ struct bfd_link_info *info = (struct bfd_link_info *) inf;
+
+ info->flags |= DF_TEXTREL;
+
+ /* Not an error, just cut short the traversal. */
+ return FALSE;
+ }
+ }
+ return TRUE;
+}
+
/* Set the sizes of the dynamic sections. */
static bfd_boolean
@@ -3666,6 +3699,12 @@
return FALSE;
}
+ /* If any dynamic relocs apply to a read-only section,
+ then we need a DT_TEXTREL entry. */
+ if ((info->flags & DF_TEXTREL) == 0)
+ elf_link_hash_traverse (&htab->root, elf32_arm_readonly_dynrelocs,
+ (PTR) info);
+
if ((info->flags & DF_TEXTREL) != 0)
{
if (!add_dynamic_entry (DT_TEXTREL, 0))
[-- Attachment #3: Type: text/plain, Size: 1627 bytes --]
Solves my DT_TEXTREL problem but needs more testing.
As a related question, in the original elf32-arm.h, the check for
DF_TEXTREL was done outside the if(relocs):
if (relocs)
{
if ( !add_dynamic_entry (DT_REL, 0)
|| !add_dynamic_entry (DT_RELSZ, 0)
|| !add_dynamic_entry (DT_RELENT, sizeof
(Elf32_External_Rel)))
return FALSE;
}
if ((info->flags & DF_TEXTREL) != 0)
{
if (!add_dynamic_entry (DT_TEXTREL, 0))
return FALSE;
info->flags |= DF_TEXTREL;
}
but in elf32-i386.c and elf32-s390.c, the DF_TEXTREL handling is done
inside the if(relocs):
if (relocs)
{
if (!add_dynamic_entry (DT_REL, 0)
|| !add_dynamic_entry (DT_RELSZ, 0)
|| !add_dynamic_entry (DT_RELENT, sizeof
(Elf32_External_Rel)))
return FALSE;
/* If any dynamic relocs apply to a read-only section,
then we need a DT_TEXTREL entry. */
if ((info->flags & DF_TEXTREL) == 0)
elf_link_hash_traverse (&htab->elf, readonly_dynrelocs,
(PTR) info);
if ((info->flags & DF_TEXTREL) != 0)
{
if (!add_dynamic_entry (DT_TEXTREL, 0))
return FALSE;
}
}
Is this an issue in elf32-arm.h or a simply small optimization that
causes no trouble otherwise?
--
David Poole <dpoole _at_ mobl.com>
Mobility Electronics, Idaho http://www.mobl.com
960 Broadway Avenue, Suite 300
Boise, ID 83706
next prev parent reply other threads:[~2004-06-01 16:59 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-05-28 15:24 David Poole
2004-05-28 15:33 ` Daniel Jacobowitz
2004-05-28 15:54 ` David Poole
2004-05-28 22:58 ` David Poole
2004-05-29 6:21 ` Alan Modra
2004-06-01 16:59 ` David Poole [this message]
2004-10-29 20:13 ` Daniel Jacobowitz
2004-10-30 13:17 ` Richard Earnshaw
2004-11-01 15:14 ` Nick Clifton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=FF30F76A-B3EC-11D8-93CF-000393CDE218@mbuf.com \
--to=daveml@mbuf.com \
--cc=binutils@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).