Bug 16773 - Cannot process a R_X86_64_TPOFF32 against .tdata
Summary: Cannot process a R_X86_64_TPOFF32 against .tdata
Status: RESOLVED FIXED
Alias: None
Product: binutils
Classification: Unclassified
Component: gold (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Cary Coutant
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-03-29 05:44 UTC by Rafael Ávila de Espíndola
Modified: 2014-10-06 12:36 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments
testcase (275 bytes, application/x-object)
2014-03-29 05:44 UTC, Rafael Ávila de Espíndola
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Rafael Ávila de Espíndola 2014-03-29 05:44:54 UTC
Created attachment 7501 [details]
testcase

I was curious if R_X86_64_TPOFF32 would work if given .tdata and an offset instead of a regular symbol.

I don't see a reason why it shouldn't, given that it is just an offset. It works with bfd ld, but not gold:

$ gcc test.o -fuse-ld=bfd -o test && ./test; echo $?
42
$ gcc test.o -fuse-ld=gold -o test && ./test; echo $?
Segmentation fault
139
Comment 1 Sourceware Commits 2014-09-26 20:35:17 UTC
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "gdb and binutils".

The branch, master has been updated
       via  5efeedf61e4fe720fd3e9a08e6c91c10abb66d42 (commit)
      from  a73c2b56cd87f709fb9118232b19cdf516edfb10 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=5efeedf61e4fe720fd3e9a08e6c91c10abb66d42

commit 5efeedf61e4fe720fd3e9a08e6c91c10abb66d42
Author: Cary Coutant <ccoutant@google.com>
Date:   Fri Sep 26 13:34:27 2014 -0700

    Fix handling of relocations against TLS section symbols.
    
    Gold doesn't handle relocations against the section symbol for a TLS
    section correctly. Instead of using the offset of the section relative
    to the TLS segment, it uses the address of the actual section.  This
    patch checks for section symbols for TLS sections, and treats them
    the same as TLS symbols.
    
    gold/
    	PR gold/16773
    	* object.cc (Sized_relobj_file): Compute value of section symbols
    	for TLS sections the same as TLS symbols.

-----------------------------------------------------------------------

Summary of changes:
 gold/ChangeLog |    6 ++++++
 gold/object.cc |    4 +++-
 2 files changed, 9 insertions(+), 1 deletions(-)
Comment 2 Cary Coutant 2014-09-26 20:39:40 UTC
Fixed on trunk.

How did you generate test.o? Can the compiler generate the relocation against the .tdata section symbol, or did you do this through assembler? If I can make a test case for this without resorting to assembly code, it would be nice.
Comment 3 Rafael Ávila de Espíndola 2014-10-06 12:36:00 UTC
(In reply to Cary Coutant from comment #2)
> Fixed on trunk.
> 
> How did you generate test.o? Can the compiler generate the relocation
> against the .tdata section symbol, or did you do this through assembler? If
> I can make a test case for this without resorting to assembly code, it would
> be nice.

I found this (and pr16794) while trying to find out if llvm could produce these relocations. It worked with bfd, but not with gold.

Thanks for fixing this bug. I will update the comment on llvm's source code so that it can start producing them at some point.