[Qt-creator] Remote GDB debugging.

[Tim Hutt]

Oooooh, ok that makes sense now. Except I'm still not sure what to put in
the "Run Settings" screen. What do you have set as your executable?

I will actually have to give up for now anyway, as rebuilding ARM gdb for
Windows with python support apparently can only be done from Ubuntu (or
OSX) neither of which I have easy access to currently.




On 6 June 2014 12:56, Poenitz Andre <Andre.Poenitz at digia.com> wrote:

> Tim Hutt wrote:
> > I don't really understand why I have to specify a debugger,
> > and therefore what to use as a debugger. As I understand it,
> > the Segger J-Link GDB server listens on a TCP port (2331),
> >  and I gave QtCreator that port, so now it can just connect to
> > it and send GDB commands right?
>
> No. GDB_server_ does not understand GDB ("client") commands.
> That's two completely different protocols.
>
> > Why would it need a GDB executable?
>
> Creator talks to GDB (which uses Python as internal scripting
> language) that's configured for your target, and this GDB talks
> to a GDB server (or something else that speaks the same
> protocol).
>
> > In any case, I tried the gdb which came with the GNU Arm
> > Embedded compiler I am using. Apparently it doesn't support
> > python so I can't use it.
>
> Generally you can build GDB yourself from source, Get sources
> e.g. from git://sourceware.org/git/gdb.git, make sure to have
> Python development package in reach, and ./configure
> --target=arm-none-linux-gnueabi
>
> On Windows it's a bit more involved, take a look at
> dist/gdb/Makefile.mingw in your Qt Creator sources.
>
> > I also tried the MingW GDB which came with the Qt SDK.
> > That at least starts.
>
> That GDB build understands your local Windows .exe's,
> it doesn't know anything about ARM targets.
>
> > None of this makes any sense.
>
> ...
>
> > And as for the Run settings. I am only given one option and there is
> > no way around it. If I press the debug button with no executable set,
> > it shows the dialog below:
>
> That's not surprising, as you try to start a local executable.
>
> > It seems to work best if I set the executable to my "foo.out" file -
> > at least then the GDB sessions says the breakpoints are synchronised
> > (when I'm using the Qt SDK version of GDB - not the Arm Embedded one).
>
> > But then it tries to send `run c:\Users\me\blah\blah\foo.out` in
> > gdb and that obviously doesn't work.
>
> ...
>
> > It would really help if you could post screen-shots of your Kits,
> > Debuggers, Compilers and Run settings!!
>
> On not-so-recent Ubuntu with yesterdays Creator from "master"
> branch I have for an STM32F4 board the following setup:
>
> - in the Bare Metal device set up:
> Gdb host: |/usr/local/bin/openocd -c "gdb_port pipe" -c "log_output
> openocd.log;" -f board/stm32f4discovery.cfg
> Gdb port: 3333
> Gdb commands: set remote hardware-breakpoint-limit 6  \
>  set remote hardware-watchpoint-limit 4 \
>  monitor reset halt \  load \  monitor reset halt
>
> - in the Build and Run/Debugger page an entry pointing to
> /data/dev/debugger/gdb-git-arm-none-eabi-install/bin/arm-none-eabi-gdb
> (which is a self-build GDB as described above)
>
> - in the Build and Run/Compiler page an entry pointing to
> /usr/bin/arm-none-eabi-g++
>
> - in the Build and Run/Kits page an entry combining those
> (BareMetal device, the debugger, and the compiler)
>
> Once the tool chain is set up and Tim's example project from
> https://gitorious.org/mbed-for-baremetal-qtcreator is loaded
> pressing "Run" gives me a nicely blinking LED within 3 seconds.
>
> Andre'
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/qt-creator/attachments/20140606/838ef80c/attachment.html>