> 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 <[email protected]> wrote: > 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
