public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
* Cross debugger
@ 2011-06-16  2:00 Chris Sutcliffe
  2011-06-16  2:54 ` Joel Brobecker
  0 siblings, 1 reply; 5+ messages in thread
From: Chris Sutcliffe @ 2011-06-16  2:00 UTC (permalink / raw)
  To: gdb

Hi All,

I'm trying to debug a binary I made using the x86_64-w64-mingw32 cross
compiler toolchain hosted on Cygwin.  To that end I've attempted to
create an x86_64-w64-mingw32 cross debugger by specifying
'--target=x86_64-w64-mingw32' when configuring gdb 7.2.  It worked in
that a gdb.exe and gdbtui.exe were created (thought there was no
gdbserver.exe created).  I was off to a great start, in that this
cross debugger was able to load the 64-bit binary, find the symbols
and I was even able to set break points.  I then tried to start the
executable and that's where I hit the wall.  I couldn't get gdb to run
the executable:

(gdb) start
Temporary breakpoint 2 at 0x40f2e0: file
/home/user/mingw64/mingw64-x86_64-runtime-1.0b_svn4075-1/src/mingw-w64-crt/crt/crt0_c.c,
line 17.
Starting program: /usr/src/emerge/experimental/Source/bin64/emergeLauncher.exe
Don't know how to run.  Try "help target".

I'm running this on a 64-bit Win7 machine, so I would assume it should
know how to run it.  Did I miss something when creating this cross
debugger?

Thank you,

Chris

-- 
Chris Sutcliffe
http://emergedesktop.org
http://www.google.com/profiles/ir0nh34d

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Cross debugger
  2011-06-16  2:00 Cross debugger Chris Sutcliffe
@ 2011-06-16  2:54 ` Joel Brobecker
  2011-06-16 11:54   ` Chris Sutcliffe
  0 siblings, 1 reply; 5+ messages in thread
From: Joel Brobecker @ 2011-06-16  2:54 UTC (permalink / raw)
  To: Chris Sutcliffe; +Cc: gdb

> I'm trying to debug a binary I made using the x86_64-w64-mingw32 cross
> compiler toolchain hosted on Cygwin.  To that end I've attempted to
> create an x86_64-w64-mingw32 cross debugger by specifying
> '--target=x86_64-w64-mingw32' when configuring gdb 7.2.  It worked in
> that a gdb.exe and gdbtui.exe were created (thought there was no
> gdbserver.exe created).

The gdbserver will be automatically built only when host = target,
which is not your case.

What I don't understand is why you created a cross compiler/debugger,
while it seems to me you could have just created a native x64 MinGW
toolset.  That's what we do at AdaCore: We use cygwin as the build
environment, but then build a MinGW toolset by configuring with
--build=x86_64-pc-mingw32. As far as I know, the gdbserver will
be automatically built.

And if you can't build a native x64 MinGW compiler (for instance
if you can't find an x86_64-mingw32 compiler), you can still
use your cross compiler to cross-build a native MinGW GDB. Or
you can use that cross compiler to cross-build a native MinGW
GCC, and then use that to build GDB.

> (gdb) start
[...]
> Don't know how to run.  Try "help target".

And that's also expected, since you have a cross-debugger. So the
debugger is expecting you to connect to the target where the process
is running.

But the nice thing is that, if I understand your situation correctly,
as soon as you build a native debugger, you will not have to worry
about that anymore.

-- 
Joel

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Cross debugger
  2011-06-16  2:54 ` Joel Brobecker
@ 2011-06-16 11:54   ` Chris Sutcliffe
  2011-06-16 13:54     ` Paul Koning
  0 siblings, 1 reply; 5+ messages in thread
From: Chris Sutcliffe @ 2011-06-16 11:54 UTC (permalink / raw)
  To: gdb

On 15 June 2011 22:53, Joel Brobecker wrote:
> What I don't understand is why you created a cross compiler/debugger,
> while it seems to me you could have just created a native x64 MinGW
> toolset.  That's what we do at AdaCore: We use cygwin as the build
> environment, but then build a MinGW toolset by configuring with
> --build=x86_64-pc-mingw32. As far as I know, the gdbserver will
> be automatically built.

Good point, for some reason I was thinking that since gdb would be
running withing the Cygwin environment I would need the
'--host=i686-pc-cygwin'.  If I build a native x64 MinGW gdb will it
understand Cygwin paths correctly?

>> (gdb) start
> [...]
>> Don't know how to run.  Try "help target".
>
> And that's also expected, since you have a cross-debugger. So the
> debugger is expecting you to connect to the target where the process
> is running.

Ah, I didn't realize a cross-debugger could only be used to connect to
running process.

> But the nice thing is that, if I understand your situation correctly,
> as soon as you build a native debugger, you will not have to worry
> about that anymore.

Indeed, I hope so.

Thank you,

Chris

-- 
Chris Sutcliffe
http://emergedesktop.org
http://www.google.com/profiles/ir0nh34d

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Cross debugger
  2011-06-16 11:54   ` Chris Sutcliffe
@ 2011-06-16 13:54     ` Paul Koning
  2011-06-16 14:19       ` Pedro Alves
  0 siblings, 1 reply; 5+ messages in thread
From: Paul Koning @ 2011-06-16 13:54 UTC (permalink / raw)
  To: Chris Sutcliffe; +Cc: gdb


On Jun 16, 2011, at 7:53 AM, Chris Sutcliffe wrote:

> On 15 June 2011 22:53, Joel Brobecker wrote:
>> What I don't understand is why you created a cross compiler/debugger,
>> while it seems to me you could have just created a native x64 MinGW
>> toolset.  That's what we do at AdaCore: We use cygwin as the build
>> environment, but then build a MinGW toolset by configuring with
>> --build=x86_64-pc-mingw32. As far as I know, the gdbserver will
>> be automatically built.
> 
> Good point, for some reason I was thinking that since gdb would be
> running withing the Cygwin environment I would need the
> '--host=i686-pc-cygwin'.  If I build a native x64 MinGW gdb will it
> understand Cygwin paths correctly?
> 
>>> (gdb) start
>> [...]
>>> Don't know how to run.  Try "help target".
>> 
>> And that's also expected, since you have a cross-debugger. So the
>> debugger is expecting you to connect to the target where the process
>> is running.
> 
> Ah, I didn't realize a cross-debugger could only be used to connect to
> running process.

More precisely, it can attach to an already running process, or you can start a new one on the command line.  Either way, though, by the time gdb connects to gdbserver, the process already exists.  If you started it on the command line, it's on the first instruction (typically some sort of startup library code, well before "main").  So either way, you get things going by "continue".

	paul

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Cross debugger
  2011-06-16 13:54     ` Paul Koning
@ 2011-06-16 14:19       ` Pedro Alves
  0 siblings, 0 replies; 5+ messages in thread
From: Pedro Alves @ 2011-06-16 14:19 UTC (permalink / raw)
  To: gdb; +Cc: Paul Koning, Chris Sutcliffe

On Thursday 16 June 2011 14:52:24, Paul Koning wrote:
> 
> On Jun 16, 2011, at 7:53 AM, Chris Sutcliffe wrote:
> 
> > On 15 June 2011 22:53, Joel Brobecker wrote:
> >> What I don't understand is why you created a cross compiler/debugger,
> >> while it seems to me you could have just created a native x64 MinGW
> >> toolset.  That's what we do at AdaCore: We use cygwin as the build
> >> environment, but then build a MinGW toolset by configuring with
> >> --build=x86_64-pc-mingw32. As far as I know, the gdbserver will
> >> be automatically built.
> > 
> > Good point, for some reason I was thinking that since gdb would be
> > running withing the Cygwin environment I would need the
> > '--host=i686-pc-cygwin'.  If I build a native x64 MinGW gdb will it
> > understand Cygwin paths correctly?
> > 
> >>> (gdb) start
> >> [...]
> >>> Don't know how to run.  Try "help target".
> >> 
> >> And that's also expected, since you have a cross-debugger. So the
> >> debugger is expecting you to connect to the target where the process
> >> is running.
> > 
> > Ah, I didn't realize a cross-debugger could only be used to connect to
> > running process.
> 
> More precisely, it can attach to an already running process, or you can start a new one on the command line.  Either way, though, by the time gdb connects to gdbserver, the process already exists.  If you started it on the command line, it's on the first instruction (typically some sort of startup library code, well before "main").  So either way, you get things going by "continue".

That's a bit orthogonal to cross-debuggers.  It's "target remote"
that doesn't know how to "start".  "target extended-remote" does know.

When you're not already connected to a remote target, "run"/"start"
will try to run the program with the native debugger.  If there's
no native debugger in your gdb build (because you've built gdb as
a cross debugger only), then you'll see that message, because
your gdb doesn't know how to run the program natively.

Those commands _can_ be used with a cross-debugger.  You need to
connect to a remote target that knows how.  That is what the
--multi switch of gdbserver is for.  Start gdbserver with e.g.,

 "gdbserver --multi :9999"

and connect to it from gdb with "target extended-remote".

You can then use "run", "start", and "attach", just like you
would if you were debugging with a native debugger.

-- 
Pedro Alves

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2011-06-16 14:19 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-06-16  2:00 Cross debugger Chris Sutcliffe
2011-06-16  2:54 ` Joel Brobecker
2011-06-16 11:54   ` Chris Sutcliffe
2011-06-16 13:54     ` Paul Koning
2011-06-16 14:19       ` Pedro Alves

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).