Re: debugging an Atmel EB40 with a Jeeni

Fernando Nasser
2000-09-25T11:53:00Z

Shaun Jackman wrote:
>
> I have an Atmel EB40. I'm using GDB and a Jeeni to debug it.
> When I set the ARM CPSR register, I get a data abort.
> This shouldn't touch data at all. What's happening?
> This GDB was configured as "--host=i586-pc-linux-gnu --target=arm-elf"...
> (gdb) target rdi e=jeeni
> JEENI (ADP, ARM7TDI) Rev 2.0
> Rebuilt on Oct 18 1999 at 18:31:13
> SN=0009J002 ENET=00:80:CF:00:09:E4
> IP=192.168.2.2
> Connected to ARM RDI target.
> (gdb) set $cpsr=0x1f
> RDI_read: data abort, no memory at specified address?
> RDI_read: data abort, no memory at specified address?
> Cannot access memory at address 0x852b5a7c
> (gdb)
> The address (0x852b5a7c) is way out in lala land and if
> anything tried to access it it would definately cause a data abort.
>
> Also, a really strange issue with a block memory clear hanging.
> This GDB was configured as "--host=i586-pc-linux-gnu --target=arm-elf"...
> (gdb) target rdi e=jeeni
> JEENI (ADP, ARM7TDI) Rev 2.0
> Rebuilt on Oct 18 1999 at 18:31:13
> SN=0009J002 ENET=00:80:CF:00:09:E4
> IP=192.168.2.2
> Connected to ARM RDI target.
> (gdb) set *(int*)0xffe00020=1
> (gdb) set *(int*)0xffe00004=0x2002121
> (gdb) set *(char*)0x20005a3 = 0
> (gdb) set *(char*)0x20005a4 = 0
> (gdb) set *(char*)0x20005a5 = 0
> (gdb) set (char[0x5a5])*0x2000000={}
> [hangs here, never hear a word from it again]
>
> The two writes to 0xffe0xxxx map the sram to 0x2000000.
> All the above writes work just fine, but any block clear larger than 0x5a4 hangs it.
> Any idea what's happening here?
>

I have no idea, but we can know a little bit more if you turn log on.
Better double check the help, but if I remember well it goes like that:
(gdb) set rdilogfile <yourfile-or-/dev/tty>
(gdb) set rdilogenable true

Maybe you should turn log on after the connection so you don't get too much log.
This should give us a clue.

--
Fernando Nasser
Red Hat - Toronto E-Mail: fnasser@cygnus.com
2323 Yonge Street, Suite #300 Tel: 416-482-2661 ext. 311
Toronto, Ontario M4P 2C9 Fax: 416-482-6299
From ac131313@cygnus.com Mon Sep 25 12:28:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Michael Elizabeth Chastain <chastain@cygnus.com>
Cc: cgf@cygnus.com, dj@delorie.com, gdb@sourceware.cygnus.com
Subject: Re: 'char **environ' woes with cygwin
Date: Mon, 25 Sep 2000 12:28:00 -0000
Message-id: <39CFA681.AF0946F@cygnus.com>
References: <200008251825.LAA32754@train2.cygnus.com>
X-SW-Source: 2000-09/msg00136.html
Content-length: 913

Michael Elizabeth Chastain wrote:
>
> Ok, here's a patch against sourceware that rips out the "environ" crap.
> I haven't even built with it.
>
> After doing the math, the fixed address "&environ" cancels out. So this
> won't make things any worse (or better) for djgpp or other systems where
> malloc() does more than increment an sbrk pointer.
>
> Chris, do you think this makes your life easier enough to warrant some
> testing and integration into sourceware?
>
> Michael

Can this change be simplified further? Vis:

o save an sbrk() call
at the start to get the current
top of heap

o call sbrk () at the display time
time and use that to compute
the size.

Also can the nasty bit of math used to make the computation be pushed
into a function somewhere?

I think your proposed change just needs to be pushed a little bit
further so that all the nasties are eliminated :-)

enjoy,
Andrew
From ac131313@cygnus.com Mon Sep 25 12:34:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: lars brinkhoff <lars@nocrew.org>
Cc: gdb@sourceware.cygnus.com
Subject: Re: PDP-10
Date: Mon, 25 Sep 2000 12:34:00 -0000
Message-id: <39CFA7E0.A7F93C52@cygnus.com>
References: <853djurgax.fsf@junk.nocrew.org> <39A641B6.25EDF1E1@cygnus.com> <8566oke1a7.fsf@junk.nocrew.org>
X-SW-Source: 2000-09/msg00137.html
Content-length: 708

lars brinkhoff wrote:

> > It may take a little (lot of) work :-( findvar.c contains:

>
> I'm willing to give it a try. Would it be acceptable for inclusion in
> GDB?

As a remote target? Yes. As native target, maybe :-)

GDB needs to get its act together with respect to sizeof host/target
char. With respect to a native GDB, well, that could be more
interesting again. However, provided there is an active maintainer it
is still a possibility - depends mostly on the level of damage.

The main thing is to get the issues out in the public domain early so
that people can understand what changes (and in particular new
programming conventions) are going to be needed for this to work

Enjoy,
Andrew
From chastain@cygnus.com Mon Sep 25 12:42:00 2000
From: Michael Elizabeth Chastain <chastain@cygnus.com>
To: ac131313@cygnus.com, chastain@cygnus.com
Cc: cgf@cygnus.com, dj@delorie.com, gdb@sourceware.cygnus.com
Subject: Re: 'char **environ' woes with cygwin
Date: Mon, 25 Sep 2000 12:42:00 -0000
Message-id: <200009251945.MAA13853@train2.cygnus.com>
X-SW-Source: 2000-09/msg00138.html
Content-length: 283

Andrew Cagney wrote:

> I think your proposed change just needs to be pushed a little bit
> further so that all the nasties are eliminated :-)

OK, I will push it a little bit further and submit it as a sourceware
patch. But it's a weekend task rather than a weekday task.

Michael
From ac131313@cygnus.com Mon Sep 25 12:44:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: gdb-announce@sources.redhat.com
Cc: gdb@sources.redhat.com
Subject: [maint] Add Mark Kettenis to blanket write privs maintainers
Date: Mon, 25 Sep 2000 12:44:00 -0000
Message-id: <39CFAA4A.78C34214@cygnus.com>
X-SW-Source: 2000-09/msg00139.html
Content-length: 228

Hello,

In response to many many recommendations (and happily accepted by Mark),
I've added Mark K to the list of ``Blanket Write Privs'' GDB
maintainers.

Mark, you've been doing an amazing job! Thanks from everyone.

Andrew
From ac131313@cygnus.com Mon Sep 25 13:12:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: RDBrown@mira.net, RodneyBrown@mynd.com
Cc: Geoff Keating <geoffk@cygnus.com>, gdb@sources.redhat.com
Subject: Re: Preferred format of Copyright statement
Date: Mon, 25 Sep 2000 13:12:00 -0000
Message-id: <39CFB0B7.7A445052@cygnus.com>
References: <200008162301.JAA00501@iji.local>
X-SW-Source: 2000-09/msg00140.html
Content-length: 1097

> > I know this has a tendency to line-wrap, but so what? No human will
> > ever care. So we might as well make it completely correct.
>
> Ok, will produce that form.
> Given that the first attempt over gdb
> gives a patch file of ~900k touching 1725 files, would it be more useful
> to provide patches for the few percent of cases needing manual fixes and
> provide the script to be run when the maintainer finds it convenient?
> Or should it only fix those with ranges or 2-digit years and leave (C)
> removal where the year list is Ok?
>
> (Trying to conserve maintainer think time, not be a WOFTAM).

(Yes I know your e-mail was posted a month ago :-().

Could I suggest a multi-step process like Kevin is doing to clean up
PARAMS. I'd suggest doing the automated changes and then as a later
pass, do the hand changes. You won't need maintainer approval for this
change. Just give a weeks notice on the big jumbo change.

enjoy,
Andrew

PS: I my take on how to format copyright is that IanC's guideline is
simply too complicated for us programming types - we're a simple bunch
:-)
From cgf@cygnus.com Mon Sep 25 13:30:00 2000
From: Chris Faylor <cgf@cygnus.com>
To: Michael Elizabeth Chastain <chastain@cygnus.com>
Cc: ac131313@cygnus.com, dj@delorie.com, gdb@sourceware.cygnus.com
Subject: Re: 'char **environ' woes with cygwin
Date: Mon, 25 Sep 2000 13:30:00 -0000
Message-id: <20000925162926.D12392@cygnus.com>
References: <200009251945.MAA13853@train2.cygnus.com>
X-SW-Source: 2000-09/msg00141.html
Content-length: 532

On Mon, Sep 25, 2000 at 12:45:09PM -0700, Michael Elizabeth Chastain wrote:
>Andrew Cagney wrote:
>
>> I think your proposed change just needs to be pushed a little bit
>> further so that all the nasties are eliminated :-)
>
>OK, I will push it a little bit further and submit it as a sourceware
>patch. But it's a weekend task rather than a weekday task.

I agree.

Also, for what it's worth, this change is no longer required for Cygwin.
I was trying to work around a header file change that turned out to be
an actual bug.

cgf
From sjackman@ed.gray.internal Mon Sep 25 13:56:00 2000
From: Shaun Jackman <sjackman@ed.gray.internal>
To: gdb@sources.redhat.com
Subject: Re: debugging an Atmel EB40 with a Jeeni
Date: Mon, 25 Sep 2000 13:56:00 -0000
Message-id: <Pine.LNX.4.21.0009251452260.994-100000@ed.gray.internal>
References: <39CF9F0E.1A9D5231@cygnus.com>
X-SW-Source: 2000-09/msg00142.html
Content-length: 2351

On Mon, 25 Sep 2000, Fernando Nasser wrote:

> Shaun Jackman wrote:
> >
> > I have an Atmel EB40. I'm using GDB and a Jeeni to debug it.
> > When I set the ARM CPSR register, I get a data abort.
> > This shouldn't touch data at all. What's happening?
> > This GDB was configured as "--host=i586-pc-linux-gnu --target=arm-elf"...
> > (gdb) target rdi e=jeeni
> > JEENI (ADP, ARM7TDI) Rev 2.0
> > Rebuilt on Oct 18 1999 at 18:31:13
> > SN=0009J002 ENET=00:80:CF:00:09:E4
> > IP=192.168.2.2
> > Connected to ARM RDI target.
> > (gdb) set $cpsr=0x1f
> > RDI_read: data abort, no memory at specified address?
> > RDI_read: data abort, no memory at specified address?
> > Cannot access memory at address 0x852b5a7c
> > (gdb)
> > The address (0x852b5a7c) is way out in lala land and if
> > anything tried to access it it would definately cause a data abort.
> >
> > Also, a really strange issue with a block memory clear hanging.
> > This GDB was configured as "--host=i586-pc-linux-gnu --target=arm-elf"...
> > (gdb) target rdi e=jeeni
> > JEENI (ADP, ARM7TDI) Rev 2.0
> > Rebuilt on Oct 18 1999 at 18:31:13
> > SN=0009J002 ENET=00:80:CF:00:09:E4
> > IP=192.168.2.2
> > Connected to ARM RDI target.
> > (gdb) set *(int*)0xffe00020=1
> > (gdb) set *(int*)0xffe00004=0x2002121
> > (gdb) set *(char*)0x20005a3 = 0
> > (gdb) set *(char*)0x20005a4 = 0
> > (gdb) set *(char*)0x20005a5 = 0
> > (gdb) set (char[0x5a5])*0x2000000={}
> > [hangs here, never hear a word from it again]
> >
> > The two writes to 0xffe0xxxx map the sram to 0x2000000.
> > All the above writes work just fine, but any block clear larger than 0x5a4 hangs it.
> > Any idea what's happening here?
> >
>
> I have no idea, but we can know a little bit more if you turn log on.
> Better double check the help, but if I remember well it goes like that:
> (gdb) set rdilogfile <yourfile-or-/dev/tty>
> (gdb) set rdilogenable true
>
> Maybe you should turn log on after the connection so you don't get too much log.
> This should give us a clue.

I wasn't able to find any rdi log or debug commands.

(gdb) help set rdi
Ambiguous set command "rdi": rdiheartbeat, rdiromatzero.

There were some remote* commands (remotedebug, remotelogfile), but as I
understand it these have no effect with rdi. They only work with remote
gdb stubs.

Is there a rdi debug mode I can't find?

Thanks,
Shaun