On Nov 13, 2012, at 12:18 PM, Sean Silva <[email protected]> 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
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
