bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug gold/17699] incorrect R_386_TLS_DTPMOD32 relocation


From: ccoutant at gmail dot com
Subject: [Bug gold/17699] incorrect R_386_TLS_DTPMOD32 relocation
Date: Wed, 23 Nov 2016 02:59:31 +0000

https://sourceware.org/bugzilla/show_bug.cgi?id=17699

Cary Coutant <ccoutant at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |INVALID

--- Comment #6 from Cary Coutant <ccoutant at gmail dot com> ---
I can't find any support for the claims made in Comment #1.

In all ABIs using the IA-64 TLS model, the DTPMOD relocation is defined as
resolving to the index of the load module where the *referenced symbol* is
defined. Thus, the r_sym field of the relocation is relevant, and is used by
the dynamic linker to determine what load module index to insert into the GOT
entry. In the case of a reference to a local symbol, the local symbol can be
(and usually is) collapsed to a section symbol, and the dynamic loader resolves
the relocation to the index of the current load module (which is where the
local symbol is defined).

It appears that Gnu ld has adopted a convention where a 0 symbol index may also
be used to refer to the current load module, but that convention is not
described in the ABI, as far as I can determine, nor does the dynamic linker
depend on it.

In my opinion, the musl dynamic linker was written to conform to one specific
implementation (viz, the Gnu linker), and not to the specification.

Section symbols in the dynamic symbol table are not only perfectly valid, but
are used frequently -- whether for TLS or not. They do not depend on the
section table any more than any other symbol, since the value of a symbol in an
executable is always a proper virtual address.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]