MaskRay wrote: > > and lack of upstream runtime linker (rtld) support > > @MaskRay We actually have proof-of-concept support for musl > [access-softek/musl@cbf25fb](https://github.com/access-softek/musl/commit/cbf25fbb2aaff125e232d5126dce7936f70a6453) > (probably not ready for meaningful production usage though), and the signed > GOT implementation which is submitted to upstream via multiple PRs (including > this one) is actually working: I'm able to run binaries compiled and linked > with signed GOT (and also `-z pac-plt` for signed PLT GOT, but it's a > different story). > > So, as for me we can expose the flag right now.
Yes, I know there is a musl fork, but it's not the official upstream. musl project tends to be cautious when accepting hardening features. Additionally, deployment experience might be limited. There are many examples we don't expose driver options: * There are many Intel JCC Erratum options but few are ever customized by uses. The very few users just specify -mbranches-within-32B-boundaries * address sanitizer has a lot of internal options customization instrumentation. We would probably not be comfortable exposing many of them. https://github.com/llvm/llvm-project/pull/96160 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
