-ftls-model docs/implementation inconsistency

-ftls-model docs/implementation inconsistency

[Alexander Monakov]

Hello,

Suppose a user builds a non-PIC shared object for x86 target with gcc by
passing -shared but not -fPIC.  This works, but internally GCC will not set
flag_shlib (as flag_shlib == flag_pic && !flag_pie).  

Suppose further the user loads that shared object at runtime with dlopen.  For
that to work reliably, any TLS data there must be allocated with local-dynamic
or global-dynamic model.  However, since flag_shlib was not set,
varasm.c:decl_default_tls_model will choose local-exec or initial-exec.

The documentation for -ftls-model option promises that the user can override
the choice from command line:

-ftls-model=model
  Alter the thread-local storage model to be used.  The model argument should
  be one of "global-dynamic", "local-dynamic", "initial-exec" or "local-exec".

However the implementation does not allow arbitrary overriding:

decl_default_tls_model (const_tree decl)
{ 
  if (!flag_shlib)
    kind = is_local ? TLS_MODEL_LOCAL_EXEC : TLS_MODEL_INITIAL_EXEC;
  else
    kind = is_local ? TLS_MODEL_LOCAL_DYNAMIC : TLS_MODEL_GLOBAL_DYNAMIC;

  if (kind < flag_tls_default)
    kind = flag_tls_default;

  return kind;
} 

(code edited by hand for brevity; actual source:
http://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/varasm.c#l5985 ).

The TLS_* values are such that TLS_MODEL_GLOBAL_DYNAMIC < TLS_MODEL_LOCAL_EXEC.

Thus, the implementation of -ftls-model allows to clamp storage to faster,
less general models, but does not allow to force slower, more general models.
This prevents building safely dlopen'able non-PIC shared objects without
resorting to using attributes to mark TLS data explicitely as global-dynamic.
This behavior is from day one as far as I could trace it:
http://gcc.gnu.org/ml/gcc-patches/2002-05/msg01912.html

It follows that the documentation is wrong or incomplete.  I also think the
implementation should be changed to allow what the documentation promises.
I can fix either, but I need to know which.  Please advise.

I'll also appreciate comments on whether the inability to set flag_shlib
without -fPIC is entirely intended and WONTFIX.

Thanks.
Alexander

Re: -ftls-model docs/implementation inconsistency

[Jakub Jelinek]

On Fri, Jul 19, 2013 at 07:34:30PM +0400, Alexander Monakov wrote:
> Suppose a user builds a non-PIC shared object for x86 target with gcc by
> passing -shared but not -fPIC.  This works, but internally GCC will not set
> flag_shlib (as flag_shlib == flag_pic && !flag_pie).  

Usually it doesn't (on many targets the linker will just fail to link it),
on others it is highly undesirable and various security policies might
refuse to load such DT_TEXTREL shared libraries.
Furthermore, on Linux you can dlopen even libraries with initial-exec TLS
model in it (as long as they don't use too big TLS sections).

So the short answer is, don't do this, especially if you are using TLS.

	Jakub

Re: -ftls-model docs/implementation inconsistency

[Alexander Monakov]

On Fri, 19 Jul 2013, Jakub Jelinek wrote:
> Furthermore, on Linux you can dlopen even libraries with initial-exec TLS
> model in it (as long as they don't use too big TLS sections).

This is the failure I'm referring to ("cannot load any more object ..."):
http://repo.or.cz/w/glibc.git/blob/HEAD:/elf/dl-open.c#l525

> So the short answer is, don't do this, especially if you are using TLS.

Sure, *I* don't do that.  The problem is, some GCC users do that, and we
should either fix the documentation, or fix the implementation to match the
documentation and give them a smoother rope.  I'd do the latter, but I don't
see if there were any reasons for the current implementation to be the way it
is, and hence I'm asking on the mailing list.

Thanks.
Alexander

Re: -ftls-model docs/implementation inconsistency

[Jakub Jelinek]

On Fri, Jul 19, 2013 at 07:55:35PM +0400, Alexander Monakov wrote:
> On Fri, 19 Jul 2013, Jakub Jelinek wrote:
> > Furthermore, on Linux you can dlopen even libraries with initial-exec TLS
> > model in it (as long as they don't use too big TLS sections).
> 
> This is the failure I'm referring to ("cannot load any more object ..."):
> http://repo.or.cz/w/glibc.git/blob/HEAD:/elf/dl-open.c#l525
> 
> > So the short answer is, don't do this, especially if you are using TLS.
> 
> Sure, *I* don't do that.  The problem is, some GCC users do that, and we
> should either fix the documentation, or fix the implementation to match the
> documentation and give them a smoother rope.  I'd do the latter, but I don't
> see if there were any reasons for the current implementation to be the way it
> is, and hence I'm asking on the mailing list.

The change of memory models based on flag_shlib is completely intentional,
it is similar to the linker TLS optimizations but at the compiler level,
so if you want to ad some comment to documentation, that is fine, but
I don't see anything to fix.

	Jakub

Re: -ftls-model docs/implementation inconsistency

[Alexander Monakov]

On Fri, 19 Jul 2013, Jakub Jelinek wrote:
> The change of memory models based on flag_shlib is completely intentional,
> it is similar to the linker TLS optimizations but at the compiler level,
> so if you want to ad some comment to documentation, that is fine, but
> I don't see anything to fix.

The problem is that -ftls-model flag allows forcing local-exec TLS in
shared objects, but does not allow forcing global-dynamic TLS.  I don't see
the rationale for providing one but not the other.  It seems inconsistent.

Thanks.
Alexander

Re: -ftls-model docs/implementation inconsistency

[Jakub Jelinek]

On Fri, Jul 19, 2013 at 08:08:26PM +0400, Alexander Monakov wrote:
> On Fri, 19 Jul 2013, Jakub Jelinek wrote:
> > The change of memory models based on flag_shlib is completely intentional,
> > it is similar to the linker TLS optimizations but at the compiler level,
> > so if you want to ad some comment to documentation, that is fine, but
> > I don't see anything to fix.
> 
> The problem is that -ftls-model flag allows forcing local-exec TLS in
> shared objects, but does not allow forcing global-dynamic TLS.  I don't see
> the rationale for providing one but not the other.  It seems inconsistent.

If user code has __attribute__((tls_model ("global-dynamic"))) and the
compiler determines that it is not going to be used in a shared library,
then it of course optimizes it to a better code, and if we did that only at
the ld time, the generated code would be worse.  That is the common case,
the case where people compile incorrectly objects that they want to link
into shared libraries is simply a user error that we shouldn't in any way
promote or support.

	Jakub

Re: -ftls-model docs/implementation inconsistency

[Alexander Monakov]

On Fri, 19 Jul 2013, Jakub Jelinek wrote:
> If user code has __attribute__((tls_model ("global-dynamic"))) and the
> compiler determines that it is not going to be used in a shared library,
> then it of course optimizes it to a better code

I see your point, but that's not how tls_model attribute works in today's GCC.
It takes precedence over -ftls-model flag and whatever GCC deduced from
flag_shlib and binds_local_p in decl_default_tls_model.  So if the user wants
to force a specific allocation they can do so with the attribute.

> That is the common case, the case where people compile incorrectly objects
> that they want to link into shared libraries is simply a user error that we
> shouldn't in any way promote or support.

On 32-bit x86, some GCC users will do that regardless (citing PIC overhead as
the reason for going non-PIC; I don't want to defend this position, I'm just
explaining a possible motivation).  Even if the attribute didn't work, they
could revert to pthread_setspecific and co. for TLS.  I don't see why make
using GCC harder for them.

Thanks again.
Alexander