Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
Nice! There are enough comments below that I won't hit "accept" just yet, but none of the comments are blocking and you can talk me out of all of them if you disagree with the suggestions.
llvm/utils/gn/build/BUILD.gn | ||
---|---|---|
138 ↗ | (On Diff #181406) | "crt" means "c runtime library" in my head. I guess "compiler_rt_code" is too long for you? |
llvm/utils/gn/secondary/BUILD.gn | ||
15 ↗ | (On Diff #181406) | Maybe android_aarch64_toolchain = "//llvm/utils/gn/build/toolchain:stage2_android_aarch64" deps += [ ""//compiler-rt/lib/hwasan:hwasan_shared($android_aarch64_toolchain)" ... ? |
llvm/utils/gn/secondary/compiler-rt/lib/hwasan/BUILD.gn | ||
4 ↗ | (On Diff #181406) | assert(current_os == "android") or something like that up here (ldflags etc assume this) |
31 ↗ | (On Diff #181406) | This is the first source_set :-) I went with static_library almost everywhere because
If you think source_set is the thing to do here it's fine to keep this as-is, just wanted to mention it. |
53 ↗ | (On Diff #181406) | In all the other build files, I kept these alphabetical (config, deps, sources) (except that I put public_configs next to configs). I thought I saw a recommended order somewhere once but couldn't find it. If this is the recommended order, can you point me to where the recommendation is? Then I'll change all the other build files. Else, if I'm making up the memory of there being a public recommendation, it's probably good to make the order here consistent with the order in all the existing build files. |
79 ↗ | (On Diff #181406) | I think we currently unconditionally pass T to ar; probably need some mechanism to not do this for static libaries you want to be "really" complete. (cf https://cs.chromium.org/chromium/src/build/config/compiler/BUILD.gn?q=complete_static_lib+file:build/config&sq=package:chromium&g=0&l=1679 too) |
llvm/utils/gn/secondary/compiler-rt/lib/ubsan/BUILD.gn | ||
---|---|---|
1 ↗ | (On Diff #181406) | How closely do we want to follow CMake target names? For example, in CMake build this target is called RTUbsan (add_compiler_rt_object_libraries also adds .<arch> but that's an implementation detail). |
llvm/utils/gn/secondary/compiler-rt/lib/hwasan/BUILD.gn | ||
---|---|---|
31 ↗ | (On Diff #181406) | CMake build uses object libraries, which is GN source set equivalent, for various targets in runtimes, typically to share objects between static and shared libraries, and those use cases are exactly what source sets are intended for so this is IMO fine. |
- Address review comments
llvm/utils/gn/build/BUILD.gn | ||
---|---|---|
138 ↗ | (On Diff #181406) | I have a mild preference for crt_ as I was going to name variables and such crt_foo in upcoming patches, and I wanted the prefix to be short and consistent. But if you think crt_ is too confusing, let me know. |
llvm/utils/gn/secondary/BUILD.gn | ||
15 ↗ | (On Diff #181406) | Sure, that'll do for now, although I intend to replace this whole block with a reference to a test target (without the toolchain stuff since it will be refactored inside the test target) in an upcoming patch. |
llvm/utils/gn/secondary/compiler-rt/lib/hwasan/BUILD.gn | ||
53 ↗ | (On Diff #181406) | I've done this for the library targets (and removed empty lines and moved output_* to the top since that seems to be the style too). I couldn't find a consistent style for action so I left as is. |
79 ↗ | (On Diff #181406) | We'll probably need something like that if/when we start creating installable packages. This will do for now because we can just assume that the object files will be present on disk. |
llvm/utils/gn/secondary/compiler-rt/lib/ubsan/BUILD.gn | ||
1 ↗ | (On Diff #181406) | I don't think it's worth copying the target names here. CMake is subject to other constraints (e.g. the target name has to be unique throughout the build) and the name I've chosen makes it a little clearer that this is a source set and therefore behaves as a source set when linked into other targets. |
cmake build seems to have a lot of flags that are not in gn, ex. -fno-builtin and more in SANITIZER_COMMON_CFLAGS.
It's possible that they don't matter for hwasan, but I thought I'd mention it anyway.
Yes, those missing flags didn't cause any issues for me with hwasan. I'd expect that as support for more sanitizers is added we'd need to make the flags used look more like the cmake build.