This is an archive of the discontinued LLVM Phabricator instance.

gn build: Add build files for compiler-rt/lib/{hwasan,interception,sanitizer_common,ubsan}.
ClosedPublic

Authored by pcc on Jan 11 2019, 5:38 PM.

Details

Summary

This allows the hwasan runtime to be built for Android aarch64 (but
currently r347650 needs to be reverted because of pr40250).

Depends on D56626

Depends on D56627

Diff Detail

Event Timeline

pcc created this revision.Jan 11 2019, 5:38 PM

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

"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

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

assert(current_os == "android") or something like that up here (ldflags etc assume this)

31

This is the first source_set :-) I went with static_library almost everywhere because

  • llvm-config expects the presence of many of the llvm libs
  • the chromium build used source_sets pervasively at first but that was bad for binary size and link time, so many of that had to be undone

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

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

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)

phosek added inline comments.Jan 11 2019, 8:28 PM
llvm/utils/gn/secondary/compiler-rt/lib/ubsan/BUILD.gn
1

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).

phosek added inline comments.Jan 11 2019, 8:36 PM
llvm/utils/gn/secondary/compiler-rt/lib/hwasan/BUILD.gn
31

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.

pcc updated this revision to Diff 181700.Jan 14 2019, 7:06 PM
pcc marked 7 inline comments as done.
  • Address review comments
llvm/utils/gn/build/BUILD.gn
138

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

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

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

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

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.

pcc updated this revision to Diff 181701.Jan 14 2019, 7:11 PM
  • Also update the other files
thakis accepted this revision.Jan 15 2019, 6:06 AM
This revision is now accepted and ready to land.Jan 15 2019, 6:06 AM
This revision was automatically updated to reflect the committed changes.

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.

pcc added a comment.Jan 15 2019, 2:04 PM

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.