[cfe-commits] r167799 - /cfe/trunk/lib/Driver/Tools.cpp

[Sean Silva]

> The amount I know about dtrace can fit on a postage stamp. :-) I do know that when we did a 'sample' of the process, it was stuck processing some debugging information. I have sources and am going to try to debug this myself.

Ok. Ping me if you need any help.

-- Sean Silva

On Tue, Nov 13, 2012 at 3:58 PM, Bill Wendling <isanbard at gmail.com> wrote:
> On Nov 13, 2012, at 12:18 PM, Sean Silva <silvas at purdue.edu> wrote:
>
>> Hi Bill, what part of DTrace is using DWARF info? AFAIK the only part
>> of DTrace that looks at debug info is ctfconvert, is that what you are
>> referring to when you say "dtrace"? (or is this a new DTrace feature,
>> like being able to give a line number with a PID probe?)
>>
> Hi Sean,
>
> The amount I know about dtrace can fit on a postage stamp. :-) I do know that when we did a 'sample' of the process, it was stuck processing some debugging information. I have sources and am going to try to debug this myself.
>
>>> If we build LLVM in LTO mode  and then run dtrace on the executable, it will
>>> eat all of your memory and fill up your hard drive because of bad debug info
>>> resulting from bad accelerator tables.
>>
>> When you say "run dtrace on the executable", that (to me) means something like
>> dtrace -n'syscall:::entry {@[execname] = count();}' -c './llc ...'
>> , and dtrace(1M) shouldn't write anything to disk when doing that.
>>
>> Could you give more detail about how what commands and stuff are
>> causing DTrace to "thrash"? I know DTrace inside and out (well, except
>> possibly for unreleased new features...), so feel free to be as
>> specific as you would like.
>>
>
> This is the command we run:
>
> $ /Volumes/Data/clang-bni-builds/clang-999.roots/clang-999/order-files/gen-clang-order-data --no-sudo \
> --cc /Volumes/Data/clang-bni-builds/clang-999.roots/clang-999~obj/x86_64/Release/bin/clang \
> --inputs /Volumes/Data/clang-bni-builds/clang-999.roots/clang-999/order-files/inputs \
> --temps /Volumes/Data/clang-bni-builds/clang-999.roots/clang-999~obj/order-data/x86_64/temps \
> --outputs /Volumes/Data/clang-bni-builds/clang-999.roots/clang-999~obj/order-data/x86_64/data
>
> And this is what that script is actually running:
>
> gen-clang-order-data:108: note: generating dtrace data for test 'pch-gen-Cocoa.driver': \
> '"dtrace" "-xevaltime=exec" "-xmangled" "-xbufsize=1m" "-q" \
> "-n" "oneshot$target:::entry/probemod=="clang"/ { printf("TS: %d\\n", timestamp); ustack(1); }" \
> "-c" "/Volumes/Data/clang-bni-builds/clang-999.roots/clang-999~obj/x86_64/Release/bin/clang \
> -x objective-c-header Cocoa_Prefix.h -o /Volumes/Data/clang-bni-builds/clang-999.roots/clang-999~obj/order-data/x86_64/temps/Cocoa_Prefix_Precompiled.h.gch -###"'
>
> The purpose is to create an "order" file so that we can reorder how things are linked to get better performance. The clang that's being tested here is built with LTO and -gline-tables-only. We know that debug info with LTO doesn't work. So if dtrace looks at the debug info at all, it may get confused. dwarfdump has a 'verify' option which is how I found out that the accelerator tables were messed up. If I remove the accelerator tables, dwarfdump claims that the debug info is fine. But dtrace still eats up all memory...
>
> -bw
>
>