headers
Τ¶«É½ | 1 May 2005 20:40

arm-linux-gdb show "Don't know how to run"

1. I have install gdb5.3 as follow:
   ./configure --target=arm-linux
   make
   make install

2. I wrote a simply program "hello.c":
   arm-linux-gcc -g -o hello hello.c

3. When i used the arm-linux-gdb to debug, it showed:
   
#arm-linux-gdb hello
GNU gdb 5.3
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General
Public License, and you are
welcome to change it and/or distribute copies of
it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type
"show warranty" for details.
This GDB was configured as
"--host=i686-pc-linux-gnu --target=arm-linux"...
(gdb) run
Starting program:
/friendly-arm/root/examples/hello/hello
Don't know how to run.  Try "help target".


Who can help me? Thank you!
(Continue reading)

Permalink | Reply | 0 comments |
headers
Daniel Jacobowitz | 1 May 2005 21:00

Re: arm-linux-gdb show "Don't know how to run"

On Mon, May 02, 2005 at 02:40:02AM +0800, Τ¶«É½ wrote:
> 1. I have install gdb5.3 as follow:
>    ./configure --target=arm-linux

This is a cross debugger.

> (gdb) run
> Starting program:
> /friendly-arm/root/examples/hello/hello
> Don't know how to run.  Try "help target".

You have to tell it how to connect to your target.  For arm-linux, you
should probably read the documentation for "gdbserver".

--

-- 
Daniel Jacobowitz
CodeSourcery, LLC
Permalink | Reply | 0 comments |
headers
Eli Zaretskii | 1 May 2005 21:46
Picon

Re: Windows support in GDB

> Date: Fri, 29 Apr 2005 09:43:35 -0700
> From: Mark Mitchell <mark <at> codesourcery.com>
> CC: paul <at> codesourcery.com,  gdb <at> sourceware.org
> 
> Christopher Faylor wrote:
> 
> > However, now that the patches are finally here, I have to say that I
> > sort of share Mark K's concerns.  I'm wondering if we are on a slippery
> > slope and (to mix a metaphor) will be subjecting gdb to a
> > death-by-inches as we slowly add ifdefs throughout the configury and
> > code.
> 
> I think it's a funny time to get concerned -- we're done. :-)  There are 
> no more cuts coming, so as long as we're not bleeding to death yet, 
> we're not going to die.  Plenty of GNU software has similar patches to 
> support running on MinGW.  GDB itself already has 2500 lines of code in 
> win32-nat.c, some of which I would imagine is rather more opaque to 
> POSIX programmers than anything we've added.
> 
> We made these changes with no algorithmic modifications to GDB, no 
> perversions of its core design, etc.

FWIW, I agree with Mark M. here: the changes added to support MinGW
were minimal, almost unnoticed in the sources.

> I certainly don't think the entire codebase will be littered with 
> HANDLEs and ReadFileEx, or transformed into a multi-threaded application 
> with a Windows event loop in the middle of it, or anything like that.

Perhaps we should have a mingw.c file to hide any such code, should
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eli Zaretskii | 1 May 2005 21:51
Picon

Re: Windows support in GDB

> Date: Fri, 29 Apr 2005 12:58:31 -0400
> From: Kris Warkentin <kewarken <at> qnx.com>
> CC: mark <at> codesourcery.com,  paul <at> codesourcery.com,  gdb <at> sourceware.org
> 
> It isn't just an issue of gdb not working with native paths because,
> as you say, it _usually_ does.  It's a question of consistency.

Indeed.

In fact, any serious use of GDB will almost instantly bump into such a
consistency (or lack thereof) issue.  For example, will the `edit' and
`shell' commands work if I don't have a Cygwin Bash installed and GDB
is configured to invoke that Bash as the shell?
Permalink | Reply | 3 comments |
headers
Eli Zaretskii | 1 May 2005 22:01
Picon

Re: Windows support in GDB

> Date: Fri, 29 Apr 2005 09:14:34 -0700
> From: Mark Mitchell <mark <at> codesourcery.com>
> CC: paul <at> codesourcery.com,  gdb <at> sourceware.org
> 
> The fundamental reason for us to use it is that our customers say -- 
> strongly -- that they do not want to use Cygwin.  (In contrast, I use 
> Cygwin every day.)

I hope you use the MinGW ports at least as much as you use Cygwin.
Because if those who work on porting tools don't put their own ports
to some serious use, those tolls will remain, well, less ported.
Permalink | Reply | 2 comments |
headers
Mark Mitchell | 1 May 2005 22:06

Re: Windows support in GDB

Eli Zaretskii wrote:
>>Date: Fri, 29 Apr 2005 09:14:34 -0700
>>From: Mark Mitchell <mark <at> codesourcery.com>
>>CC: paul <at> codesourcery.com,  gdb <at> sourceware.org
>>
>>The fundamental reason for us to use it is that our customers say -- 
>>strongly -- that they do not want to use Cygwin.  (In contrast, I use 
>>Cygwin every day.)
> 
> 
> I hope you use the MinGW ports at least as much as you use Cygwin.
> Because if those who work on porting tools don't put their own ports
> to some serious use, those tolls will remain, well, less ported.

I do.  In fact, I'm almost always using MinGW hosted toolchains -- but I 
use Cygwin for things like emacs, bash, and all those other familiar GNU 
tools. :-)

--

-- 
Mark Mitchell
CodeSourcery, LLC
mark <at> codesourcery.com
(916) 791-8304
Permalink | Reply | 1 comment |
headers
Eli Zaretskii | 1 May 2005 22:09
Picon

Re: Windows support in GDB

> Date: Fri, 29 Apr 2005 12:51:48 -0400
> From: Christopher Faylor <me <at> cgf.cx>
> 
> >What's the failure mode going to be?  If a POSIX person adds a use of
> >non-Windows function, without appropriate #ifdef, then the Windows side
> >of things will break.  At that point, assuming that people are noticing
> >(which we will!), we'll fix that.
> 
> I guess the failure mode will be roughly similar to DJGPP.  Every time
> someone decides that it would be nice to use signal(), select(), fifos,
> inodes, unix-domain sockets, or some other non-msdos construct there
> will have to be a discussion about how to make things work.  But, I
> guess we'd already be having this discussion to with DJGPP so maybe it
> won't be a big deal.

DJGPP has less problems than MinGW because DJGPP is more Posix
compliant.  E.g., out of the non-msdos constructs you mentioned, DJGPP
has `signal', `select', and inodes.

But yes, quite a few of Unixish assumptions already bit the dust since
the DJGPP port is part of GDB.  IS_ABSOLUTE_PATH and similar
abstractions come to mind, as does DIRNAME_SEPARATOR.  Undoubtedly,
this is one reason why the MinGW port additions were relatively minor.
Permalink | Reply | 0 comments |
headers
Eli Zaretskii | 1 May 2005 22:20
Picon

Re: Windows support in GDB

> Date: Sun, 01 May 2005 13:06:39 -0700
> From: Mark Mitchell <mark <at> codesourcery.com>
> CC: me <at> cgf.cx,  paul <at> codesourcery.com,  gdb <at> sourceware.org
> 
> I use Cygwin for things like emacs, bash, and all those other
> familiar GNU tools. :-)

There's a native Windows port of Emacs, FWIW.  It works fine with
MinGW ports of GNU software.

Bash is another matter (although I don't quite understand why there's
no MinGW port of it, since there's an excellent DJGPP port which could
be used as a starting point).  I use an old port of zsh when I really
need a Unixy shell on Windows.
Permalink | Reply | 0 comments |
headers
lin q | 1 May 2005 23:21
Picon
Favicon

"Incomplete Type"

Hi,
  This is a question about DDD, hopefully it is not so off-topic in this 
group.

  I am using DDD 3.3.1 with gdb 6.3 and when I use "Display" command to 
display some complex type data value, it always shows as "incomplete type".

I am pretty sure that all the code are compiled with -g option and in 
starting DDD, I define all the source file paths through --directory option.

Do you know what might go wrong?

Thanks a lot.

_________________________________________________________________
Don’t just search. Find. Check out the new MSN Search! 
http://search.msn.click-url.com/go/onm00200636ave/direct/01/
Permalink | Reply | 0 comments |
headers
Christopher Faylor | 1 May 2005 23:41

Re: Windows support in GDB

On Sun, May 01, 2005 at 10:51:02PM +0300, Eli Zaretskii wrote:
>> Date: Fri, 29 Apr 2005 12:58:31 -0400
>> From: Kris Warkentin <kewarken <at> qnx.com>
>> CC: mark <at> codesourcery.com,  paul <at> codesourcery.com,  gdb <at> sourceware.org
>> 
>> It isn't just an issue of gdb not working with native paths because,
>> as you say, it _usually_ does.  It's a question of consistency.
>
>Indeed.
>
>In fact, any serious use of GDB will almost instantly bump into such a
>consistency (or lack thereof) issue.  For example, will the `edit' and
>`shell' commands work if I don't have a Cygwin Bash installed and GDB
>is configured to invoke that Bash as the shell?

And, if they don't, what's the solution?  You fix it so they will work.
Presumably, if there is no /bin/sh.exe available, you'd use a fallback.
You could even implement a switch to force cygwin's gdb into "windows
path mode".

Problems like "what happens when there is no cygwin shell available?"
are fixable.  They are likely to be fixable without the necessity of
sprinkling ifdefs all over gdb or even making changes to the configury.
I don't think that they can be used as a justification for a windows
port.

No matter how you slice it, changes to get gdb working on native windows
are at least mildly intrusive.  Maybe compatibility changes to make a
cygwin-based gdb work better would be equally intrusive or time
consuming.  I *suspect* however, that fixing cygwin's gdb to better
(Continue reading)

Permalink | Reply | 2 comments |

Gmane