On Tue, Sep 9, 2025 at 10:36 AM Alexander Monakov <amona...@ispras.ru> wrote:
>
>
>
> On Tue, 9 Sep 2025, H.J. Lu wrote:
>
> > On Tue, Sep 9, 2025 at 9:04 AM Alexander Monakov <amona...@ispras.ru> wrote:
> > >
> > >
> > > On Tue, 9 Sep 2025, H.J. Lu wrote:
> > >
> > > > > > to restore assert if not compiling for shared library. When
> > > > > > compiling
> > > > > > for shared library, the recomputed model may be weaker.
> > > > >
> > > > > I don't understand why (for shared libraries), can you explain?
> > > >
> > > > Another shared library or executable may override any global
> > > > symbols with the default visibility in a shared library.
> > >
> > > I know that symbols with default visibility can be interposed, but that
> > > doesn't
> > > answer the question. Do you have a testcase that demonstrates the issue?
> >
> > TLS tests were submitted at
> >
> > https://patchwork.sourceware.org/project/gcc/patch/20250908221002.3223418-1-hjl.to...@gmail.com/
> >
> > The key point is that compiler doesn't know if PIC code will be in
> > shared library or executable.
>
> But this doesn't imply that recomputed model would be weaker.
>
> As I understand, the actual issue is that decl_default_tls_model does not
> iterate the attribute list, and so can return a weaker model than what the
> front-end assigned based on the attribute. But this doesn't seem to have
> any relation to -fpic and shared libraries: you'll be in the same situation
The interposiblility is controlled by targetm.binds_local_p,
which is orthogonal to the TLS model.
> with extern TLS:
>
> __attribute__((tls_model("local-exec")))
> extern __thread int tls_undef;
>
> where decl_default_tls_model returns initial-exec instead. Is this situation
> covered by existing tests? I expect your
>
> gcc_checking_assert (flag_shlib || new_model >= model);
>
> to fail on this.
This is covered by c-c++-common/tls-attr-le-pic.c in
https://patchwork.sourceware.org/project/gcc/patch/20250908221002.3223418-1-hjl.to...@gmail.com/
>
>
> > > > x/1 (x)
> > > > Type: variable definition analyzed
> > > > Visibility: externally_visible semantic_interposition public common
> > > > References:
> > > > Referring: f/3 (addr)
> > > > Availability: overwritable
> > > > Varpool flags: tls-local-exec
> > >
> > > Thanks. Unrelated to this particular patch, but this is questionable: we
> > > have
> > > local-exec for an interposable (Availability: overwritable) symbol.
> > > Perhaps
> >
> > Definition in executable isn't interposable.
>
> But it's not a strong definition, it's common symbol. Anyway, just take
> attribute-common instead of attribute-weak: weak symbols are interposable.
>
Since weak definition in executable can only be overridden by a strong
definition in executable, weak attribute makes no difference.
--
H.J.
