This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch+7.12.1 2/2] Fix TLS (such as 'errno') regression

On Mon, 10 Oct 2016 16:50:38 +0200, Tom Tromey wrote:
> My only question about this patch is why the symbol's section has a
> non-zero section offset.  Is that the reason why?
> Maybe it would make sense to make a SEC_THREAD_LOCAL section always have
> a zero offset.  Then touching all the users wouldn't be necessary.

IIUC you mean this subexpression could be zero (which it is not):
	ANOFFSET ((objfile)->section_offsets, ((symbol)->mginfo.section)

Section Headers:
  [Nr] Name              Type            Address          Off    Size   ES Flg Lk Inf Al
  [19] .tdata            PROGBITS        0000000000200db4 000db4 000004 00 WAT  0   0  4
Symbol table '.symtab' contains 71 entries:
   Num:    Value          Size Type    Bind   Vis      Ndx Name
    54: 0000000000000000     4 TLS     GLOBAL DEFAULT   19 thread_local

All the sections have the same offset for PIE - the PIE load base address.

And I do not think it is correct to set that offset to zero for SHF_TLS as the
thread initialization data is really located at the section address relocated
by that PIE-load-base address.

> On the third hand it seems strange to even try to get the "address" of a
> TLS symbol in this way.

There could be a symbol's getter which asserts/throws on reading address of
a TLS symbol?  Maybe, not a part of this patch.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]