Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Unit Tests
Time | Test | |
---|---|---|
29,590 ms | x64 debian > libFuzzer.libFuzzer::fork.test |
Event Timeline
Obviously needs work/cleanup, changes to x86, and tests, but posting for early feedback about module level attributes vs function level attributes, or possibly something else. I tested this quickly with thin LTO of the Linux kernel and it worked.
clang/lib/CodeGen/CodeGenModule.cpp | ||
---|---|---|
776–783 | I should add tests for these; that clang emits these module attributes as expected. |
llvm/include/llvm/IR/Module.h | ||
---|---|---|
898 | TODO: delete this comment |
I haven't looked through in too much detail, but I see you have the module flag type set as Warning on conflict. I guess the answer to module level vs function level depends on whether it is valid to link together files compiled with different values of these flags and if so what the expected behavior should be. How does this work on non-LTO? If it works just fine, i.e. the functions from the modules with one value are compiled ok with that value and linked with functions compiled effectively with another value, then that would point to a function attribute so you can mimic the mix-and-match behavior. If it is unexpected, then perhaps better to keep as a module flag but Error? With Warning, the value from the first module being linked is used - would that be surprising?
Probably want a test using llvm-link or llvm-lto to check this behavior (that alike flags are getting propagated as expected and that conflicting ones error)
clang/include/clang/Driver/Options.td | ||
---|---|---|
3416 | What's the effect of or reason for this change? | |
clang/test/CodeGen/stack-protector-guard.c | ||
5 | Perhaps add a check that the module flags not added without these options | |
llvm/include/llvm/IR/Module.h | ||
898 | add a doxygen comment like the ones for the other interfaces here |
Not many tests under llvm/test/LTO or llvm/test/ThinLTO use llvm-link; is there a more appropriate subdir for such a test for conflicting module attributes?
clang/include/clang/Driver/Options.td | ||
---|---|---|
3416 | Of the 3 options added in D88631 (mstack_protector_guard_EQ, mstack_protector_guard_offset_EQ, mstack_protector_guard_reg_EQ) 2 are strings (mstack_protector_guard_EQ and mstack_protector_guard_reg_EQ). It was inconsistent that one could be unspecified, where as the other could be unspecified or "none" (but those 2 values were equivalent). Without this change, in clang/lib/CodeGen/CodeGenModule.cpp I'd need to check that StackProtectorGuardReg != "none" rather than !StackProtectorGuardReg.empty() below. I can change it back, but I think the asymmetry between mstack_protector_guard_EQ and mstack_protector_guard_reg_EQ in D88631, and I missed that in code review. I don't think there would be any other observers of such a change. |
Hmm, maybe in llvm/test/Linker? Or you could presumably use llvm-lto.
clang/include/clang/Driver/Options.td | ||
---|---|---|
3416 | I see. Does unspecified mean something like just "-mstack-protector-guard-reg=" with nothing after the =? I didn't realize that was supported. |
Will work on explicit LTO tests.
clang/include/clang/Driver/Options.td | ||
---|---|---|
3416 | It looks like we validate for that case in the front end already. Specifically, RenderAnalyzerOptions in clang/lib/Driver/ToolChains/Clang.cpp. $ clang -mstack-protector-guard-reg= ... clang-13: error: invalid value '' in 'mstack-protector-guard-reg=' |
clang/include/clang/Driver/Options.td | ||
---|---|---|
3416 | Does that mean that without the "none" handling there is no way to disable? I.e. overriding an earlier value. Not sure how important this is. |
llvm/test/LTO/AArch64/stack-protector-guard-module-attrs.ll | ||
---|---|---|
2–5 ↗ | (On Diff #347124) | I used llvm-link here, but please let me know if it would be preferable to convert these to use llvm-lto2 instead? Also, is there any issue with this new dir, llvm/test/LTO/AArch64/? Do I need to modify any lit cfg files so that the tests don't run for non-aarch64? Also, I guess this test isn't really specific to aarch64; I don't do any codegen and don't specify the target triple (though, these module attributes only will be emitted from the front end for x86 and aarch64 at the moment; perhaps riscv and ppc64le in the future). |
clang/include/clang/Driver/Options.td | ||
---|---|---|
3416 | Oh, that's a great point. I guess I'm not really sure of the intention of "none" then, @xiangzhangllvm can you comment whether that was the intention? A quick test in GCC shows that GCC does not accept the value "none" for either -mstack-protector-guard= or -mstack-protector-guard-reg=. We could strive to support disabling the command line flag once respecified, but I'd rather do it for both of the above two flags, not just -mstack-protector-guard-reg=. |
llvm/test/LTO/AArch64/stack-protector-guard-module-attrs.ll | ||
---|---|---|
2–5 ↗ | (On Diff #347124) | Perhaps I should move this test under llvm/test/tools/llvm-link/ or llvm/test/Linker/ ? llvm/test/Linker/ has lots of tests that invoke llvm-link. |
clang/include/clang/Driver/Options.td | ||
---|---|---|
3416 | Yeah and it doesn't look like gcc supports anything like -mno-stack-... | |
llvm/test/LTO/AArch64/stack-protector-guard-module-attrs.ll | ||
2–5 ↗ | (On Diff #347124) | Yeah I think you will want to add the aarch64 equivalent of llvm/test/LTO/X86/lit.local.cfg, even if not needed for this initial test. |
2–5 ↗ | (On Diff #347124) | That would be fine too, I don't have a strong opinion either way. I suppose since you don't need any code gen putting it under Linker would be fine (I think I'd prefer that to it going under tools/llvm-link since you aren't testing that tool specifically but rather the module linker behavior. |
clang/include/clang/Driver/Options.td | ||
---|---|---|
3416 | Sure, I'm happy to follow up on this if I got it wrong here. In the meantime, this will help our CI go back green, so I've merged it. Thank you much for the review! |
What's the effect of or reason for this change?