forked from qt-creator/qt-creator
hjk
e9237c20c6
Write the full command to a temporary file for easier re-use. Un-ignore the first stop, this does not seem to be needed in the new async setup. In some cases LLDB is not able to extract the even the top most frame of the stopped thread (happened 2 out of 100 runs of the QDateTime dumper). It's unclear why. For now just report the fact. Change-Id: I76a63bc288f1ae6f5bd9b9604a47f051912b93d7 Reviewed-by: hjk <hjk@theqtcompany.com>
The important test here is tst_dumpers.
The same build can be used to check the dumpers under different
conditions by using environment variables as follows:
QTC_DEBUGGER_PATH_FOR_TEST - path to a GDB or LLDB binary
QTC_QMAKE_PATH_FOR_TEST - path to a Qt version
QTC_MAKE_PATH_FOR_TEST - path to a "make".
Used for GDB only, defaults to "make" except on Windows,
where it defaults to "mingw32-make"
QTC_USE_GLIBCXXDEBUG_FOR_TEST - (0/1) to switch between GCC's
"normal" standard library, and the "debug" version
(this will add DEFINES += _GLIBCXX_DEBUG) to the .pro
(QTC_MSVC_ENV_BAT - to set up MSVC)
The tests should be used for automated testing, but can also
be used for dumper development and fixing.
Combinations that should always succeed are:
GDB (>=7.4), Linux (32/64), Python (2/3), Qt (4/5) - debug.
Partially work should:
Qt (4/5) - release
LLDB (Mac)
By default, only successful tests are cleaned up (use
QTC_KEEP_TEMP_FOR_TEST to override).
Failing tests leave a qt_tst_dumpers_XXXXXX directory behind,
with a 'doit.pro' which can be directly opened in Creator.
There's always a 'main.cpp' file, containing at least one
call to a function 'breakHere()'. Put a break point there,
and hit F5.
The file 'input.txt' contains the commands sent to GDB
in case something needs to be examined with the CLI debugger.