Expose -ftls-model as a multilib flag for AArch64/ARM#241
Conversation
pzhengqc
requested review from
Yethendra,
Ana Pazos (apazos),
Jonathon Penix (jonathonpenix) and
Zhaoshi Zheng (zhaoshiz)
This patch borrowed the `TLS_MODEL` variable Jonathon implemented in qualcomm#228. This also needs clang support to allow multilib selection based on `-ftls-model` (qualcomm#241). Signed-off-by: Pengxuan Zheng <pzheng@qti.qualcomm.com>
This allows multilib selection based on tls model. Signed-off-by: Pengxuan Zheng <pzheng@qti.qualcomm.com>
pzhengqc
force-pushed
the
multilib-tls-model
branch
from
5e7daba to
1ecff86
Compare
| } | ||
| } | ||
| + | ||
| + const Arg *TLSModel = Args.getLastArgNoClaim(options::OPT_ftlsmodel_EQ); |
There was a problem hiding this comment.
I'm not entirely sure, but I wonder if there needs to be something more than just looking at the command line args? In that I think the TLS model used can vary based on other options like pic, pie, etc. But I don't actually know if that information is available to us here.
(I also don't know if there is a "general" default either or if it varies per-variable.)
There was a problem hiding this comment.
It seems to me that the -ftls-model is for user to force certain tls model? I am not sure if LLVM does more than that though. We could try pushing this upstream and get some feedback. Another option is to use multilib custom flags and that should work for the purpose of selecting the variant based on tls model too. Any preferences?
There was a problem hiding this comment.
For this release, let's push a simple patch to default selected aarch64 configs to TLS Init_exec model.
And then you push the clang patch upstream to discuss with community, out of the critical path.
3 participants
This allows multilib selection based on tls model.