From: Claudiu Zissulescu <claziss@gmail.com>
To: binutils@sourceware.org
Cc: fbedard@synopsys.com
Subject: [committed] arc: Fix alignment of the TLS Translation Control Block
Date: Fri, 15 Sep 2023 13:03:49 +0300 [thread overview]
Message-ID: <20230915100349.1227137-1-claziss@gmail.com> (raw)
The R_ARC_TLS_LE_32 is defined as S + A + TLS_TBSS - TLS_REL, where
- S is the base address of the symbol in the memory
- A is the symbol addendum
- TLS_TBSS is the TLS Translation Control Block size (aligned)
- TLS_REL is the base of the TLS section
Given the next code snip:
__thread int data_var = 12;
__attribute__((__aligned__(128))) __thread int data_var_128 = 128;
__thread int bss_var;
__attribute__((__aligned__(256))) __thread int bss_var_256;
int __start(void)
{
return data_var + data_var_128 + bss_var + bss_var_256;
}
The current code returns different TLS_TBSS values for .tdata and
.tbss. This patch fixes this by using the linker provided tls_sec.
bfd/
* elf32-arc.c (TLS_REL): Clean up.
(TLS_TBSS): Use tls_sec alignment.
(arc_do_relocation): Check if we have valid tls_sec.
Signed-off-by: Claudiu Zissulescu <claziss@gmail.com>
---
bfd/elf32-arc.c | 21 +++++++++++++++++----
1 file changed, 17 insertions(+), 4 deletions(-)
diff --git a/bfd/elf32-arc.c b/bfd/elf32-arc.c
index 78dfd6eebbd..ac9970545c3 100644
--- a/bfd/elf32-arc.c
+++ b/bfd/elf32-arc.c
@@ -1226,10 +1226,8 @@ arc_special_overflow_checks (const struct arc_relocation_data reloc_data,
(bfd_signed_vma) (reloc_data.sym_section->output_section->vma)
#define JLI (bfd_signed_vma) (reloc_data.sym_section->output_section->vma)
#define _SDA_BASE_ (bfd_signed_vma) (reloc_data.sdata_begin_symbol_vma)
-#define TLS_REL (bfd_signed_vma) \
- ((elf_hash_table (info))->tls_sec->output_section->vma)
-#define TLS_TBSS (align_power(TCB_SIZE, \
- reloc_data.sym_section->alignment_power))
+#define TLS_REL (bfd_signed_vma)(tls_sec->output_section->vma)
+#define TLS_TBSS (align_power (TCB_SIZE, tls_sec->alignment_power))
#define none (0)
@@ -1307,6 +1305,7 @@ arc_do_relocation (bfd_byte * contents,
bfd * abfd = reloc_data.input_section->owner;
struct elf_link_hash_table *htab ATTRIBUTE_UNUSED = elf_hash_table (info);
bfd_reloc_status_type flag;
+ asection *tls_sec = htab->tls_sec;
if (!reloc_data.should_relocate)
return bfd_reloc_ok;
@@ -1336,6 +1335,20 @@ arc_do_relocation (bfd_byte * contents,
orig_insn = insn;
+ /* If we resolve a TLS relocation, make sure we do have a valid TLS
+ section. */
+ switch (reloc_data.howto->type)
+ {
+ case R_ARC_TLS_LE_32:
+ if (tls_sec == NULL)
+ return bfd_reloc_notsupported;
+ break;
+
+ default:
+ break;
+ }
+
+
switch (reloc_data.howto->type)
{
#include "elf/arc-reloc.def"
--
2.30.2
reply other threads:[~2023-09-15 10:03 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20230915100349.1227137-1-claziss@gmail.com \
--to=claziss@gmail.com \
--cc=binutils@sourceware.org \
--cc=fbedard@synopsys.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).