[Qt-creator] Remote GDB debugging.

[Tim Hutt]

Here's the output from WinDbg (relevant bit bolded):


ModLoad: 6d050000 6d05b000
C:\Qt\Qt5.3.0\Tools\QtCreator\bin\plugins\accessible\qtaccessiblequick.dll
ModLoad: 6c050000 6c059000
C:\Qt\Qt5.3.0\Tools\QtCreator\lib\qtcreator\qbs\plugins\qbs_cpp_scanner.dll
ModLoad: 6c110000 6c117000
C:\Qt\Qt5.3.0\Tools\QtCreator\lib\qtcreator\qbs\plugins\qbs_qt_scanner.dll
Unexpected GDB stderr: "Python Exception <type 'exceptions.ImportError'> No
module named gdb: "
Unexpected GDB stderr: "

warning:
Could not load the Python gdb module from `c:\usr\local\share\gdb/python'.
Limited Python support is available from the _gdb module.
Suggest passing --data-directory=/path/to/gdb/data-directory.

"
*SOFT ASSERT: "m_signalOperation" in file
C:\work\build\qtsdk\qt-creator\src\plugins\debugger\gdb\gdbengine.cpp, line
812*
*QObject::connect: Cannot connect (null)::finished(QString) to
Debugger::Internal::GdbRemoteServerEngine::handleInterruptDeviceInferior(QString)*
*(1084.15d8): Access violation - code c0000005 (first chance)*
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=00000005 ebx=0027c874 ecx=05c7b7b8 edx=0123017c esi=00000008
edi=0673a2e8
eip=66d883ae esp=0027c70c ebp=0682d4a8 iopl=0         nv up ei pl nz na pe
nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000
efl=00010206
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for
C:\Qt\Qt5.3.0\Tools\QtCreator\bin\Qt5Core.dll -
Qt5Core!QString::operator=+0x1e:
66d883ae 8b06            mov     eax,dword ptr [esi]
 ds:0023:00000008=????????



On 18 June 2014 11:12, Tim Hutt <tdhutt at gmail.com> wrote:

> Oh wow I finally got it to work! The key was to use the initialisation
> commands provided by Nordic (who make the nRF51822)!:
>
> mon speed 10000
>
> mon endian little
>
> mon flash download = 1
>
> mon flash device = NRF51822
>
> mon reset 0
>
>
> However, I have no discovered a segfault in QtCreator! It crashes
> ("qtcreator.exe has stopped working") if you do either of:
>
>
> 1. Manually pause program execution.
>
> 2. Add a breakpoint while the program is running.
>
>
> If you add a breakpoint before starting the debug session, or while it is
> stopped at a breakpoint, it works fine.
>
>
> So close!
>
>
> On 18 June 2014 10:58, Tim Hutt <tdhutt at gmail.com> wrote:
>
>> The same files is generated in both cases though... If it's checking for
>> the string "application" in the types list, I think that should just be
>> removed. If it's seeing if the "last" build item is an "application", or if
>> any of the explicitly specified types are "application", then I think that
>> should be changed to search the entire build tree for the "application"
>> node.
>>
>> Anyway...
>>
>> I forgot to mention that I also get this error when clicking the debug
>> button:
>>
>> [image: Inline images 1]
>>
>> What is the "inferior"?
>>
>> I also tried using "break main.cpp:51" from the official Gnu ARM Embedded
>> install (which is the one the chip maker recommend so I know it should
>> work). It had the same effect as break-insert did from QtCreator... So
>> maybe it's just that Eclipse (what they use) knows to use monitor setbp
>> instead of break? Or maybe they tell gdb how break should behave?
>>
>> I can't really find anything on the web about this - might have to
>> install Eclipse and see what commands it sends!
>>
>>
>> On 18 June 2014 07:55, Tim Sander <tim at krieglstein.org> wrote:
>>
>>> Hi Tim
>>> Am Dienstag, 17. Juni 2014, 16:52:24 schrieb Tim Hutt:
>>> > Ohhhhh my gaaahd! Finally worked it out! :-)
>>> > My fix is just to change the type to this:
>>> >       type: ["application", "hex", "size"]
>>> Well sounds plausible. Gdb uses an ELF file for debugging. Without that
>>> there's
>>> no file and nothing to run...
>>>
>>> > I haven't quite got the debugging to work yet - breakpoints are still
>>> > set with break-insert rather than setbp, but at least it connects to
>>> > the GDB server properly now, and monitor load, halt, go, and reset all
>>> > work properly!
>>> Well thats not your problem. I think that the segger debugger does not
>>> properly support the load statement? So the code running is not the code
>>> you
>>> see and so no breakpoint gets hit.
>>>
>>> > mon setbp 0x00014626
>>> Well, thats not the gdb way setting breakpoints and i know that the
>>> segger
>>> also supports break-insert.
>>>
>>> Best regards
>>> Tim
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/qt-creator/attachments/20140618/434431aa/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 20310 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/qt-creator/attachments/20140618/434431aa/attachment.png>