thesamesam wrote:
> So if the libc++ maintainers have a strong opinion about the flag, I think
> more work needs to be done to ensure a good user experience.
> Personally, I think going with the macro until the flag has more
> functionality it controls makes sense. However, I'm also not opposed
AaronBallman wrote:
I think I've got a good handle on the benefits of using a flag and agree with
many of them, but the points @MaskRay bring up are still unaddressed regarding
the complexity of supporting that flag and whether it's worth that complexity
right now. Specifically:
> The current
var-const wrote:
I personally think we absolutely should strive to add the `-fhardened` flag in
a future LLVM release with semantics broadly compatible with those of GCC.
However, we also need a separate way to control how hardening is enabled in
libc++. For one, the `-fhardened` flag doesn't
var-const wrote:
> I think that may depend on your background. For example, in the C standard
> library, there's a whole pile of `WANT` macros that users are expected to
> define before including a header file
Thanks, this is pretty interesting, and it's true that for users coming from
that w
ldionne wrote:
> I am concerned that `-fstdlib-hardening=` may not map to libstdc++ preferred
> enabling mechanism cleanly. There is a non-zero probability that GCC folks
> would not add an option that just passes a `-D...` to cc1. Then this driver
> option will feel like a libc++ specific fea
MaskRay wrote:
As mentioned, libstdc++ has `_GLIBCXX_ASSERTIONS`. The documentation is at
https://gcc.gnu.org/wiki/LibstdcxxDebugMode
https://gcc.gnu.org/onlinedocs/libstdc++/manual/debug_mode.html
> For example, in a next step we should discuss whether it makes sense for
> `-fstdlib-hardenin
AaronBallman wrote:
> Setting macros that are reserved names is really unappealing for people.
I think that may depend on your background. For example, in the C standard
library, there's a whole pile of `WANT` macros that users are expected to
define before including a header file to opt in to
@@ -7730,6 +7730,14 @@ def source_date_epoch : Separate<["-"],
"source-date-epoch">,
} // let Visibility = [CC1Option]
+def stdlib_hardening_EQ : Joined<["-"], "fstdlib-hardening=">,
cor3ntin wrote:
It is consistent with `-stdlib`
https://github.com/llvm/l
@@ -7730,6 +7730,14 @@ def source_date_epoch : Separate<["-"],
"source-date-epoch">,
} // let Visibility = [CC1Option]
+def stdlib_hardening_EQ : Joined<["-"], "fstdlib-hardening=">,
AaronBallman wrote:
I am worried about that -- I'm also worried about folk
ldionne wrote:
> > > I am on the fence whether a driver option is really needed. It is a very
> > > shallow layer of extra abstraction that a curious reader has to look
> > > through. I guess I'll not object to this, if people really want to add it.
> >
> >
> > Setting macros that are reserve
thesamesam wrote:
> > I am on the fence whether a driver option is really needed. It is a very
> > shallow layer of extra abstraction that a curious reader has to look
> > through. I guess I'll not object to this, if people really want to add it.
>
> Setting macros that are reserved names is r
ldionne wrote:
> I am on the fence whether a driver option is really needed. It is a very
> shallow layer of extra abstraction that a curious reader has to look through.
> I guess I'll not object to this, if people really want to add it.
Setting macros that are reserved names is really unappea
thesamesam wrote:
> > Yes, please, unless there's a strong reason not to, consider `-fhardened`.
>
> `-fhardened` also enables a few compiler flags. I think it would be better to
> have a separate flag that only affects the library and hopefully in the
> future start supporting `-fhardened` fl
MaskRay wrote:
I am on the fence whether a driver option is really needed. It is a very
shallow layer of extra abstraction that a curious reader has to look through. I
guess I'll not object to this, though.
https://github.com/llvm/llvm-project/pull/78763
___
https://github.com/MaskRay edited
https://github.com/llvm/llvm-project/pull/78763
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1256,6 +1256,14 @@ void Clang::AddPreprocessingOptions(Compilation &C,
const JobAction &JA,
if (Arg *A = Args.getLastArg(options::OPT_I_))
D.Diag(diag::err_drv_I_dash_not_supported) << A->getAsString(Args);
+ if (Arg *A = Args.getLastArg(options::OPT_stdlib_hardeni
var-const wrote:
> Yes, please, unless there's a strong reason not to, consider `-fhardened`.
`-fhardened` also enables a few compiler flags. I think it would be better to
have a separate flag that only affects the library and hopefully in the future
start supporting `-fhardened` flag that wou
@@ -7730,6 +7730,14 @@ def source_date_epoch : Separate<["-"],
"source-date-epoch">,
} // let Visibility = [CC1Option]
+def stdlib_hardening_EQ : Joined<["-"], "fstdlib-hardening=">,
devincoughlin wrote:
With the name `stdlib_hardening`, are we worried that
https://github.com/jkorous-apple approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/78763
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/ldionne approved this pull request.
You'll want to wait for other reviewers to also be happy with this, but from my
side this is ready to go! Thanks!
https://github.com/llvm/llvm-project/pull/78763
___
cfe-commits mailing list
cfe-c
https://github.com/ahatanak edited
https://github.com/llvm/llvm-project/pull/78763
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/ahatanak updated
https://github.com/llvm/llvm-project/pull/78763
>From 0d68286bd8b7206c5045062f65ccaf1c3fb54714 Mon Sep 17 00:00:00 2001
From: Akira Hatanaka
Date: Thu, 18 Jan 2024 16:20:41 -0800
Subject: [PATCH 1/5] Add option -fstdlib-hardening=
The option allows users to
@@ -851,6 +851,28 @@ static void InitializePredefinedMacros(const TargetInfo
&TI,
Twine(getClangFullCPPVersion()) + "\"");
// Initialize language-specific preprocessor defines.
+ if (LangOpts.getStdlibHardeningMode()) {
+const char *StdlibHardenin
https://github.com/ahatanak updated
https://github.com/llvm/llvm-project/pull/78763
>From 0d68286bd8b7206c5045062f65ccaf1c3fb54714 Mon Sep 17 00:00:00 2001
From: Akira Hatanaka
Date: Thu, 18 Jan 2024 16:20:41 -0800
Subject: [PATCH 1/4] Add option -fstdlib-hardening=
The option allows users to
https://github.com/ahatanak updated
https://github.com/llvm/llvm-project/pull/78763
>From 0d68286bd8b7206c5045062f65ccaf1c3fb54714 Mon Sep 17 00:00:00 2001
From: Akira Hatanaka
Date: Thu, 18 Jan 2024 16:20:41 -0800
Subject: [PATCH 1/3] Add option -fstdlib-hardening=
The option allows users to
@@ -7730,6 +7730,14 @@ def source_date_epoch : Separate<["-"],
"source-date-epoch">,
} // let Visibility = [CC1Option]
+def stdlib_hardening_EQ : Joined<["-"], "fstdlib-hardening=">,
+ Values<"none,fast,extensive,debug">,
+ NormalizedValues<["STDLIB_HARDENING_MODE_NONE",
@@ -275,6 +275,8 @@ def warn_drv_unknown_argument_clang_cl_with_suggestion :
Warning<
InGroup;
def err_drv_unknown_target_triple : Error<"unknown target triple '%0'">;
+def err_drv_stdlib_hardening_unavailable : Error<"libc++ hardening is
available only when libc++ is used
@@ -7730,6 +7730,14 @@ def source_date_epoch : Separate<["-"],
"source-date-epoch">,
} // let Visibility = [CC1Option]
+def stdlib_hardening_EQ : Joined<["-"], "fstdlib-hardening=">,
+ Values<"none,fast,extensive,debug">,
+ NormalizedValues<["STDLIB_HARDENING_MODE_NONE",
@@ -275,6 +275,8 @@ def warn_drv_unknown_argument_clang_cl_with_suggestion :
Warning<
InGroup;
def err_drv_unknown_target_triple : Error<"unknown target triple '%0'">;
+def err_drv_stdlib_hardening_unavailable : Error<"standard library hardening
is available only when libc
https://github.com/cor3ntin edited
https://github.com/llvm/llvm-project/pull/78763
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/cor3ntin commented:
I think this requires more documentation + a changelog entry.
(the documentation can link to a libc++ page if such thing exist, but there
needs to be an explanation of the values _somewhere_. Maybe even in the help
message too.
We probably do not want user
thesamesam wrote:
> No other thoughts for now. GCC has `-fhardened` now, which already defines
> that macro. This seems kinda redundant with it.
Yes, please, unless there's a strong reason not to, consider `-fhardened`.
Otherwise we may as well just be telling people to set `-D...` themselves.
https://github.com/ahatanak edited
https://github.com/llvm/llvm-project/pull/78763
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/ahatanak updated
https://github.com/llvm/llvm-project/pull/78763
>From 0d68286bd8b7206c5045062f65ccaf1c3fb54714 Mon Sep 17 00:00:00 2001
From: Akira Hatanaka
Date: Thu, 18 Jan 2024 16:20:41 -0800
Subject: [PATCH 1/2] Add option -fstdlib-hardening=
The option allows users to
jwakely wrote:
> Also, @jwakely it would be nice if this worked with libstdc++ as well in the
> future -- it would probably turn on checks like `__GLIBCXX_ASSERT__`.
That should be `_GLIBCXX_ASSERTIONS`
No other thoughts for now. GCC has `-fhardened` now, which already defines that
macro. Th
@@ -851,6 +851,33 @@ static void InitializePredefinedMacros(const TargetInfo
&TI,
Twine(getClangFullCPPVersion()) + "\"");
// Initialize language-specific preprocessor defines.
+ if (LangOpts.getLibcxxHardeningMode()) {
+const char *LibcxxHardenin
@@ -275,6 +275,8 @@ def warn_drv_unknown_argument_clang_cl_with_suggestion :
Warning<
InGroup;
def err_drv_unknown_target_triple : Error<"unknown target triple '%0'">;
+def err_drv_stdlib_hardening_unavailable : Error<"libc++ hardening is
available only when libc++ is used
@@ -281,6 +281,7 @@ LANGOPT(OffloadingNewDriver, 1, 0, "use the new driver for
generating offloading
LANGOPT(SYCLIsDevice , 1, 0, "Generate code for SYCL device")
LANGOPT(SYCLIsHost, 1, 0, "SYCL host compilation")
ENUM_LANGOPT(SYCLVersion , SYCLMajorVersion, 2, S
https://github.com/ldionne edited
https://github.com/llvm/llvm-project/pull/78763
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/ldionne commented:
This is nice!
Tagging a few people who might have opinions on the naming: @nico @kubamracek
@AaronBallman
Also, @jwakely it would be nice if this worked with libstdc++ as well in the
future -- it would probably turn on checks like `__GLIBCXX_ASSERT__`. Do
llvmbot wrote:
@llvm/pr-subscribers-clang-driver
Author: Akira Hatanaka (ahatanak)
Changes
The option allows users to enable libc++ hardening, which was discussed in the
following RFC:
https://discourse.llvm.org/t/rfc-hardening-in-libc/73925
Users specifiy the hardening mode by passing
https://github.com/ahatanak created
https://github.com/llvm/llvm-project/pull/78763
The option allows users to enable libc++ hardening, which was discussed in the
following RFC:
https://discourse.llvm.org/t/rfc-hardening-in-libc/73925
Users specifiy the hardening mode by passing one of the fo
42 matches
Mail list logo
