[llvm-bugs] [Bug 39347] New: rodata size bloat with file names when using -fsanitize=function with -fsanitize=address

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=39347

            Bug ID: 39347
           Summary: rodata size bloat with file names when using
                    -fsanitize=function with -fsanitize=address
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: LLVM Codegen
          Assignee: unassignedclangbugs at nondot.org
          Reporter: sugak at fb.com
                CC: llvm-bugs at lists.llvm.org

I noticed a significant bloat of .rodata section when using both
-fsanitize=function and -fsanitize=address. Inspecting the section showed that
it's significant part are strings with file names. 

I tried to use `-fsanitize-undefined-strip-path-components=-1`, but it happens
to not work with this ubsan check, and the full string names still make it into
the binary.

The repro:
```
# verify file name is not in the rodata 
% cat main.cpp
int main() {return 0;}
% clang++ -fsanitize=function $(realpath main.cpp)
% readelf -p .rodata a.out | grep main.cpp
[Exit 1] # no match

# now enable ASAN
% clang++ -fsanitize=function -fsanitize=address $(realpath main.cpp)
% readelf -p .rodata a.out | grep main.cpp
[ 17680]  /very/long/path/main.cpp

# now use -fsanitize-undefined-strip-path-components=-1
% clang++ -fsanitize=function -fsanitize=address
-fsanitize-undefined-strip-path-components=-1 $(realpath main.cpp)
% readelf -p .rodata a.out | grep main.cpp
[ 17680]  /very/long/path/main.cpp # it didn't help
```
I've also verified that the file name is not emitted to rodata when only ASAN
is used. And `-fsanitize-undefined-strip-path-components=-1` works for the
other UBSAN checks that I've used.

I was able to narrow the problem down to this block
https://github.com/llvm-mirror/clang/blob/ebb3b3ca30bc377eeebfac5e56b940f9a22b5b64/lib/CodeGen/CGExpr.cpp#L4616
Looks like -fsanize=function emits a global variable with a file name and then
ASAN instruments it. Not sure why the filename doesn't make it to the resulting
binary when ASAN is disabled.

I don't completely understand the consequences of the above-mentioned block,
but commenting it out and then rebuilding some of our binary reduses the bloat
by ~30%!

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20181019/b09cf5f2/attachment.html>