[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Bug ld/13491] New: SECREL32 relocation invalid with external symbol
From: |
venix1 at gmail dot com |
Subject: |
[Bug ld/13491] New: SECREL32 relocation invalid with external symbol |
Date: |
Mon, 12 Dec 2011 16:49:45 +0000 |
http://sourceware.org/bugzilla/show_bug.cgi?id=13491
Bug #: 13491
Summary: SECREL32 relocation invalid with external symbol
Product: binutils
Version: 2.23 (HEAD)
Status: NEW
Severity: critical
Priority: P2
Component: ld
AssignedTo: address@hidden
ReportedBy: address@hidden
Classification: Unclassified
Created attachment 6102
--> http://sourceware.org/bugzilla/attachment.cgi?id=6102
Test case for secrel32
Attempting to use SECREL32 relocation for generating TLS offsets on Windows
works perfectly if the symbol is defined in the object file it is used.
However when the symbol is defined in different object file it generates the
offset against ".text".
The following lines of code appear in coff_i386_rtype_to_howto of
bfd/coff-i386.c and I believe should account for that. But it doesn't and I
found it odd that h->type was used when similar tests used h->root.type.
if (h && (h->type == bfd_link_hash_defined
|| h->type == bfd_link_hash_defweak))
osect_vma = h->root.u.def.section->output_section->vma;
After changing from h->type to h->root.type the problem went away.
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
- [Bug ld/13491] New: SECREL32 relocation invalid with external symbol,
venix1 at gmail dot com <=