[Qt-creator] Cross-debugging Win-Linux

[Andre Poenitz]

On Sat, Mar 05, 2011 at 11:06:36AM -0800, Patrick Masotta wrote:
> I'm not cross-compiling, "I'm cross-debugging", I'm porting a console
> windows app to Linux then I do as much as I can in Visual Studio then
> I compile in a Linux VM but the final debugging without a graphic
> environment is a pain, qt-creator could be a very good tool for the
> cross-debugging scenario.

Still a pretty unusual setup. Doesn't your Linux have X? 

Anyway, there is nothing wrong with that per se, but maybe try to
understand that the focus is on more common or even "normal" setups. And
I'd go so far and call Windows->Linux crosscompilation and debugging
"normal" even if it's not well supported right now.

> Cross-debugging Android is another very
> interesting scenario for qt-creator....

[And maybe already even supported by Bogdan's port? I haven't seen
it in real life so far, though.]

> > > 2) when I launch a debug session GDB ends up looking for the
> > > source files at the working directory (always
> > > C:\Qt\qtcreator-2.1.81\) if the sources are not there I just get
> > > an assembler view; not source code. I solve the problem with a gdb
> > > command "cd <my_project_dir>" every time I run my target or now
> > > adding that line to the .gdbinit file, changing it every time I
> > > work on a different project. Can't you guys just pass that "change
> > > dir" gdb directive after launching gdb, changing the working
> > > directory to the current project directory?
> >
> > There is a setting for "Working directory" in your project's run
> > settings. Isn't that honoured?
> 
> when I run my app I use Debug/Start Debugging/Start and Attach to
> Remote Application../ then I'm asked for; Debugger:______ Local
> Executable:____ Host and Port:____ Architecture:____ GNU Target:___
> Sysroot:___ but ther's not an option for local directory (where the
> sources are), then gdb just take the qt-creator (invoking app)
> default's directtory as the current working directory, it is a pain.
> Another thing related to this is that qt-creator shoud remember the
> run parameters in a project base not in a global base, even if I have
> not a loaded project in the IDE if I invoke Debug/Start
> Debugging/Start and Attach to Remote Application.../ t/he last used
> parameters are loaded as default, I think that info should be stored
> in the project file and loaded with it...

You are abusing the tool. Start and Attach to Remote Application was
meant for "Let's have a quick look on what does this app on that
device", without the need to have a proper project. By deciding to
not use projects and sessions you are depriving yourself of the
possibility to use project information to start the debugger.
 
> > > 3) qt-creator does not save the breakpoints to the project file,
> > > it would be very handy saving them, if not I have to reset
> > > breakpoints every time I start a new debugging session....
> > 
> > Breakpoints are saved in the session. See
> > 
> > http://doc.qt.nokia.com/qtcreator-snapshot/creator-project-managing-sessions.html

> in my humble opinion I think the "sesion" file should be the project
> file itself, here Visual Studio does a good job. Why to split the
> project data on a project file and a "sesion" file independently
> handled??? I don't know, am I missing some point here?

Breakpoint data is not "project data".

The project file is meant to be shared with colleagues and to
be put into revision control systems. That's not the place where
_your_ breakpoints should go. Still you'd like to persist them for
your own convenience. That's what the sessions are for.

Andre'