REPOSITORY
rL LLVM
http://reviews.llvm.org/D10868
Files:
lldb/trunk/lldb.xcodeproj/project.pbxproj
lldb/trunk/source/Commands/CMakeLists.txt
lldb/trunk/source/Commands/CommandObjectBugreport.cpp
lldb/trunk/source/Commands/CommandObjectBugreport.h
Comment at: source/Commands/CommandObjectBugreport.cpp:72
@@ +71,3 @@
+
+char command_buffer[256];
+
I'd defined this buffer before the loop to avoid memory allocation per each
frame.
Comment at:
Comment at: source/Commands/CommandObjectBugreport.cpp:88
@@ +87,3 @@
+
+uint32_t open_options = File::eOpenOptionWrite |
File::eOpenOptionCanCreate;
+const bool append =
m_outfile_options.GetAppend().GetCurrentValue();
In
Hi clayborg, ovyalov,
Add new bugreport command to lldb
The new command add functionality to print out domain specific
information for reporting a bug. Currently the only supported
domain is stack unwinding (with bugreport unwind) but adding
new domains is fairly easy.
Address review comment about append and truncate
http://reviews.llvm.org/D10868
Files:
lldb.xcodeproj/project.pbxproj
source/Commands/CMakeLists.txt
source/Commands/CommandObjectBugreport.cpp
source/Commands/CommandObjectBugreport.h
source/Interpreter/CommandInterpreter.cpp
EMAIL
So much of the useful bug reporting information in lldb is gathered by turning
on logs BEFORE the bad thing occurs, then making it happen, then gathering the
logs that were produced as a part of that process. For instance, once a bad
unwind has occurred that info is cached, and you can't watch
I agree that we can collect only a very limited information with a single
command after the problem already occurred but my intuition is that if we want
the user to reproduce the issue then there is much lower chance that they will
submit a bug report even for people working on LLDB.
For stack
