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.
T
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 w
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 (o
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 ("
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:/e
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 co
