These new builtins support a mechanism for logging OS events, using a
printf-like format string to specify the layout of data in a buffer.
The _buffer_size version of the builtin can be used to determine the size
of the buffer to allocate to hold the data, and then __builtin_os_log_format
can write data into that buffer. This implements format checking to report
mismatches between the format string and the data arguments. Most of this
code was written by Chris Willmore.
Details
- Reviewers
bkramer - Commits
- rG06d367c6c685: Add support for __builtin_os_log_format[_buffer_size]
rG29034362ae87: Add support for __builtin_os_log_format[_buffer_size]
rC285019: Add support for __builtin_os_log_format[_buffer_size]
rC284990: Add support for __builtin_os_log_format[_buffer_size]
rL285019: Add support for __builtin_os_log_format[_buffer_size]
rL284990: Add support for __builtin_os_log_format[_buffer_size]
Diff Detail
- Build Status
Buildable 733 Build 733: arc lint + arc unit
Event Timeline
This looks good from a Clang perspective. You also might want to get review from someone who knows how the os_log API is supposed to work, as I can't comment on that.
clang/test/CodeGenObjC/os_log.m | ||
---|---|---|
13 | This is only ever compile for x86 (you have a triple in the command line). Just drop the #ifdef. |
Thanks!
For the API part, this is already in production ( https://github.com/apple/swift-clang/blob/stable/lib/CodeGen/CGBuiltin.cpp#L2071 ), so it should be OK!
CodeGen's CMakeLists.txt needs to be updated to link with clangAnalysis now, otherwise it breaks builds that use shared libraries.
Fixed in r285037.
diff --git a/lib/CodeGen/CMakeLists.txt b/lib/CodeGen/CMakeLists.txt index f5d5d69..9cf34f6 100644 --- a/lib/CodeGen/CMakeLists.txt +++ b/lib/CodeGen/CMakeLists.txt @@ -88,6 +88,7 @@ add_clang_library(clangCodeGen LINK_LIBS clangAST + clangAnalysis clangBasic clangFrontend clangLex
@bkramer : is it an OK dependency to add from a clang point of view? Or should I refactor the patch to avoid introducing it?
CodeGen depending on Analysis is fine with me. Any clang tool that builds an AST will have Analysis linked in anyways so there's virtually no cost to it.
IsPublic/IsPrivate instead of magic numbers?