Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Jan Kratochvil <jan.kratochvil@redhat.com>
To: Tom Tromey <tom@tromey.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [patch+7.12.1 2/2] Fix TLS (such as 'errno') regression
Date: Mon, 10 Oct 2016 15:13:00 -0000	[thread overview]
Message-ID: <20161010151308.GA21241@host1.jankratochvil.net> (raw)
In-Reply-To: <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


  reply	other threads:[~2016-10-10 15:13 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-09 18:57 Jan Kratochvil
2016-10-10 10:45 ` Mark Wielaard
2016-10-10 14:50 ` Tom Tromey
2016-10-10 15:13   ` Jan Kratochvil [this message]
2016-10-10 22:43     ` Tom Tromey
2017-09-06 11:58 ` Pedro Alves

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20161010151308.GA21241@host1.jankratochvil.net \
    --to=jan.kratochvil@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=tom@tromey.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox