This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch+7.12.1 2/2] Fix TLS (such as 'errno') regression
- From: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- To: Tom Tromey <tom at tromey dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Mon, 10 Oct 2016 17:13:08 +0200
- Subject: Re: [patch+7.12.1 2/2] Fix TLS (such as 'errno') regression
- Authentication-results: sourceware.org; auth=none
- References: <20161009185647.GB13645@host1.jankratochvil.net> <87shs4xnpd.fsf@tromey.com>
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.
Jan