ARM

ARM

[Larry McCourry]

When will the ARM processor be supported in gdb?




---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.512 / Virus Database: 309 - Release Date: 8/19/2003

Re: ARM

[Grant Edwards]

On Thu, Oct 23, 2003 at 02:24:19PM -0400, Larry McCourry wrote:

> When will the ARM processor be supported in gdb?

They have been for many years.

-- 
Grant Edwards
grante@visi.com

Re: ARM

[Larry McCourry]

Does the following not mean that it doesn't work?
from
http://sources.redhat.com/cgi-bin/cvsweb.cgi/~checkout~/src/gdb/PROBLEMS?con
tent-type=text/x-cvsweb-markup&cvsroot=src

...

arm-*-*

GDB's ARM target, in 6.0, has not been updated to use the new frame
mechanism.

Fortunatly the ARM target, in the GDB's mainline sources, has been
updated so people encountering problems should consider downloading a
more current GDB (http://www.gnu.org/software/gdb/current).

....

Anyway, gdb-6.0 doesn't work for me. I do the following on win2k and cygwin,
talking to an AT91EB40 board with the Angel debug monitor running:

1. arm-elf-gdb
2. set remotebaud 9600
3. target rdi com1
    gdb hangs

In hyperterm I can see angel sending "valid" stuff out the serial port when
I press reset on the board. Bincom-loaded programs work on the board.

Larry McCourry



----- Original Message -----
From: "Grant Edwards" <grante@visi.com>
To: "Larry McCourry" <lmccourry@charter.net>
Cc: <gdb@sources.redhat.com>
Sent: Thursday, October 23, 2003 2:36 PM
Subject: Re: ARM


> On Thu, Oct 23, 2003 at 02:24:19PM -0400, Larry McCourry wrote:
>
> > When will the ARM processor be supported in gdb?
>
> They have been for many years.
>
> --
> Grant Edwards
> grante@visi.com


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.512 / Virus Database: 309 - Release Date: 8/19/2003

Re: ARM

[Grant Edwards]

On Thu, Oct 23, 2003 at 02:42:48PM -0400, Larry McCourry wrote:

> Does the following not mean that it doesn't work?

That depends on your definition of "it doesn't work".  My read
is that gcc 3.3 isn't compatible with released versions of gdb.
However, I used gdb 5 with gcc 2.95 and 3.2, and it worked
swimmingly.

> Anyway, gdb-6.0 doesn't work for me. I do the following on
> win2k and cygwin, talking to an AT91EB40 board with the Angel
> debug monitor running:
> 
> 1. arm-elf-gdb
> 2. set remotebaud 9600
> 3. target rdi com1
>     gdb hangs
> 
> In hyperterm I can see angel sending "valid" stuff out the
> serial port when I press reset on the board. Bincom-loaded
> programs work on the board.

That's an RDI problem, it's got nothing to do with the frame
format incompatibility -- not to say that once you get RDI
working you won't have frame format issues.

My first guess is that serial port support in your version of
Cygwin is broken -- that has been the case at various points in
the past, and I don't know what the current situation is.

My other first guess is you've got a baud rate mismatch.

My second guess is that there's something wrong with the Angel
monitor on your board.

My third guess is that bitrot has finally killed RDI.  1/2 ;)
RDI suffers from a number of problems (not all of them my
fault), but it can usually be made to work.

Try enabling rdi protocol logging, and then we can see if gdb
is seeing what Angel is sending.  It's something like one of
the commands below:

 set maint rdilog enable
 set rdilog enable
 set maint rdilogenable on 
 set rdilogenable on 

You also may want to try disabling the rdi heartbeat feature
(in my experience it confuses the Angel monitor and make things
lock up as well).  I don't remember the exact command for that
either...
 
"Just because I wrote it, it doesn't mean I remember how to run it."
 
-- 
Grant Edwards
grante@visi.com

Re: ARM

[Jim Blandy]

"Larry McCourry" <lmccourry@CHARTER.NET> writes:
> Does the following not mean that it doesn't work?
> from
> http://sources.redhat.com/cgi-bin/cvsweb.cgi/~checkout~/src/gdb/PROBLEMS?con
> tent-type=text/x-cvsweb-markup&cvsroot=src
> 
> ...
> 
> arm-*-*
> 
> GDB's ARM target, in 6.0, has not been updated to use the new frame
> mechanism.
> 
> Fortunatly the ARM target, in the GDB's mainline sources, has been
> updated so people encountering problems should consider downloading a
> more current GDB (http://www.gnu.org/software/gdb/current).

I think that note is a bit confusing.  It's referring to the way the
ARM back end within GDB is written, not to any directly user-visible
behavior, like being compatible with some compilers but not others.

The interfaces internal to GDB that the architecture-independent and
architecture-dependent (i.e., back end) code use to handle stack
frames have changed a lot in 6.0.  The old interfaces are mostly still
around, for compatibility with back ends that nobody has updated yet,
but the new interfaces are simpler and more reliable, so in general
one suspects that problems in stack frame management might go away if
the code were brought up to date.  I think that's what the note is
trying to say.

(If the audience for the PROBLEMS file were GDB developers, then it
would be fine as written --- we can't help but notice all the
deprecated and new gdbarch methods related to frame handling.  But if
the audience is GDB users, they'll generally have no idea what the
"new frame mechanism" is, but they'll assume they should, leading them
to conclude that it is some user-visible change they haven't heard
about.  Or at least that's what happened here.)