Re: Jeeni & ARM720T with GDB

Re: Jeeni & ARM720T with GDB

[Grant Edwards]

On Wed, Nov 22, 2000 at 10:35:04AM -0000, danish iftikhar wrote:

> After load Pc shows the address : 0x8060
> 
> The start uo code is :
> (gdb) x/30i $pc
> 0x8060 <warm_reset>:    mrs     r7, cpsr
> 0x8064 <warm_reset+4>:  and     r7, r7, #31     ; 0x1f
> 0x8068 <warm_reset+8>:  cmp     r7, #19 ; 0x13
> 0x806c <warm_reset+12>: beq     0x80a0 <start>

That looks right.

>   i am not able to do step or cont but using stepi i went through this 
> startup function . It seems to loop around between 0x815c & 0x8164 and is 
> not going ahead of that .
> the code at this address is as follows :
> 
> 0x8154  <start+180>:            cmp     r1, r2
> -       0x8158  <start+184>:            beq     0x8168 <start+200>
> -       0x815c  <start+188>:            str     r0, [r1], #4
> -       0x8160  <start+192>:            cmp     r1, r2
> -       0x8164  <start+196>:            bne     0x815c <start+188>
> -       0x8168  <start+200>:            bl      0x1f194 <hal_hardware_init>
> -       0x816c  <start+204>:            bl      0x1ee10 
> <cyg_hal_invoke_constructors>
> -       0x8170  <start+208>:            bl      0x1f358 <cyg_start>

It looks to me like the debugger and emulator are working fine.
The loop you're looking at is zeroing out the bss section.  R2
should contain the address of the end of bss, and R1 should
start at the beginning of bss and increment through the whole
section.  This loop will probably execute tens of thousands of
times, so you can get pretty bored doing a stepi...

Do the addresses in R1 and R2 correspond to your bss section?

Can you set a breakpoint immediately following the loop and do
a cont?

-- 
Grant Edwards
grante@visi.com
From jimb@zwingli.cygnus.com Wed Nov 22 07:21:00 2000
From: Jim Blandy <jimb@zwingli.cygnus.com>
To: David Taylor <taylor@cygnus.com>
Cc: gdb@sourceware.cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: Re: pathmap (again)
Date: Wed, 22 Nov 2000 07:21:00 -0000
Message-id: <np1yw43ud3.fsf@zwingli.cygnus.com>
References: <200011212037.PAA22391@texas.cygnus.com>
X-SW-Source: 2000-11/msg00229.html
Content-length: 86

> Comments?

It looks reasonable.  I'd say, give it a try and see what annoys people.
From taylor@cygnus.com Wed Nov 22 08:54:00 2000
From: David Taylor <taylor@cygnus.com>
To: gdb@sourceware.cygnus.com
Cc: gdb-patches@sourceware.cygnus.com
Subject: pathmap semantics issues
Date: Wed, 22 Nov 2000 08:54:00 -0000
Message-id: <200011221653.LAA22540@texas.cygnus.com>
X-SW-Source: 2000-11/msg00230.html
Content-length: 402

Okay, here's some questions concerning how pathmap should behave:

. should it translate all paths?  Or just some paths?  If some, which?
Source paths?  Others?  That is, should it be consulted when looking
for sources?, objects?, executables?, and shared objects?

. should it be searched instead of the existing path?  Or in addition?
If in addition, which should be searched first?

Do people care?
From cgf@redhat.com Wed Nov 22 08:58:00 2000
From: Christopher Faylor <cgf@redhat.com>
To: gdb@sources.redhat.com, gdb-patches@sources.redhat.com
Subject: Re: pathmap semantics issues
Date: Wed, 22 Nov 2000 08:58:00 -0000
Message-id: <20001122115802.B7346@redhat.com>
References: <200011221653.LAA22540@texas.cygnus.com>
X-SW-Source: 2000-11/msg00231.html
Content-length: 769

On Wed, Nov 22, 2000 at 11:53:38AM -0500, David Taylor wrote:
>Okay, here's some questions concerning how pathmap should behave:
>
>. should it translate all paths?  Or just some paths?  If some, which?
>Source paths?  Others?  That is, should it be consulted when looking
>for sources?, objects?, executables?, and shared objects?
>
>. should it be searched instead of the existing path?  Or in addition?
>If in addition, which should be searched first?
>
>Do people care?

I would think that it should be "all paths".  If you've gone to the
effort of issuing the pathmap command then it must be for the reason
that you don't have the specific path on your system and need to
translate it.  So, using the pathmap translation for everything would
make sense, IMO.

cgf
From msnyder@redhat.com Wed Nov 22 09:17:00 2000
From: Michael Snyder <msnyder@redhat.com>
To: David Taylor <taylor@cygnus.com>
Cc: gdb@sourceware.cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: Re: pathmap semantics issues
Date: Wed, 22 Nov 2000 09:17:00 -0000
Message-id: <3A1BFFAF.1E9A@redhat.com>
References: <200011221653.LAA22540@texas.cygnus.com>
X-SW-Source: 2000-11/msg00232.html
Content-length: 550

David Taylor wrote:
> 
> Okay, here's some questions concerning how pathmap should behave:
> 
> . should it translate all paths?  Or just some paths?  If some, which?
> Source paths?  Others?  That is, should it be consulted when looking
> for sources?, objects?, executables?, and shared objects?
> 
> . should it be searched instead of the existing path?  Or in addition?
> If in addition, which should be searched first?


I hope it won't interfere with the path for searching for 
shared libraries.  I've just spent some effort sanifying that...
From ac131313@cygnus.com Wed Nov 22 20:55:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Discussion <gdb@sourceware.cygnus.com>
Subject: gdb@gnu.org Discussion
Date: Wed, 22 Nov 2000 20:55:00 -0000
Message-id: <3A1CA166.A24792EF@cygnus.com>
X-SW-Source: 2000-11/msg00233.html
Content-length: 148

People on this mailing list should be aware of the discussion:

http://sources.redhat.com/ml/overseers/2000-q4/threads.html#00214

	sorry,
		Andrew
From d_iftikhar@hotmail.com Wed Nov 22 23:15:00 2000
From: "danish iftikhar" <d_iftikhar@hotmail.com>
To: grante@visi.com
Cc: fnasser@cygnus.com, gdb@sourceware.cygnus.com
Subject: Re: Jeeni & ARM720T with GDB
Date: Wed, 22 Nov 2000 23:15:00 -0000
Message-id: <F285Ca3Eky00sp0yx2p0000234c@hotmail.com>
X-SW-Source: 2000-11/msg00234.html
Content-length: 3399

  Hi
     i went through the code and checked the addresses of bss as well as 
other sections and they are perfectly o.k.
  ya , grant , it's zeroing the bss address only and i was able to come out 
of that loop .
where it stucks is in <cyg_hal_invoke_constructors> : take a look at code 
below :


> > 0x8154  <start+180>:            cmp     r1, r2
> > -       0x8158  <start+184>:            beq     0x8168 <start+200>
> > -       0x815c  <start+188>:            str     r0, [r1], #4
> > -       0x8160  <start+192>:            cmp     r1, r2
> > -       0x8164  <start+196>:            bne     0x815c <start+188>
> > -       0x8168  <start+200>:            bl      0x1f194 
><hal_hardware_init>
> > -       0x816c  <start+204>:            bl      0x1ee10
<cyg_hal_invoke_constructors>
> > > > -       0x8170  <start+208>:            bl      0x1f358 <cyg_start>


  things seem to work perfectly fine for h/w initialisation .
  i wonder whether some special options have to be configured in ecos build 
to make it work. i have a basic doubt ..how the diagnostic output is handled 
.
i don't think that jeeni will be able to send it back to console ..
or will connecting through the serial port work .
is the diag printf 's are the one causing it to hang.

thanks
danish.



>From: Grant Edwards <grante@visi.com>
>To: danish iftikhar <d_iftikhar@hotmail.com>
>CC: fnasser@cygnus.com, gdb@sourceware.cygnus.com
>Subject: Re: Jeeni & ARM720T with GDB
>Date: Wed, 22 Nov 2000 08:39:21 -0600
>
>On Wed, Nov 22, 2000 at 10:35:04AM -0000, danish iftikhar wrote:
>
> > After load Pc shows the address : 0x8060
> >
> > The start uo code is :
> > (gdb) x/30i $pc
> > 0x8060 <warm_reset>:    mrs     r7, cpsr
> > 0x8064 <warm_reset+4>:  and     r7, r7, #31     ; 0x1f
> > 0x8068 <warm_reset+8>:  cmp     r7, #19 ; 0x13
> > 0x806c <warm_reset+12>: beq     0x80a0 <start>
>
>That looks right.
>
> >   i am not able to do step or cont but using stepi i went through this
> > startup function . It seems to loop around between 0x815c & 0x8164 and 
>is
> > not going ahead of that .
> > the code at this address is as follows :
> >
> > 0x8154  <start+180>:            cmp     r1, r2
> > -       0x8158  <start+184>:            beq     0x8168 <start+200>
> > -       0x815c  <start+188>:            str     r0, [r1], #4
> > -       0x8160  <start+192>:            cmp     r1, r2
> > -       0x8164  <start+196>:            bne     0x815c <start+188>
> > -       0x8168  <start+200>:            bl      0x1f194 
><hal_hardware_init>
> > -       0x816c  <start+204>:            bl      0x1ee10
> > <cyg_hal_invoke_constructors>
> > -       0x8170  <start+208>:            bl      0x1f358 <cyg_start>
>
>It looks to me like the debugger and emulator are working fine.
>The loop you're looking at is zeroing out the bss section.  R2
>should contain the address of the end of bss, and R1 should
>start at the beginning of bss and increment through the whole
>section.  This loop will probably execute tens of thousands of
>times, so you can get pretty bored doing a stepi...
>
>Do the addresses in R1 and R2 correspond to your bss section?
>
>Can you set a breakpoint immediately following the loop and do
>a cont?
>
>--
>Grant Edwards
>grante@visi.com

_____________________________________________________________________________________
Get more from the Web.  FREE MSN Explorer download : http://explorer.msn.com

Re: Jeeni & ARM720T with GDB

[Fernando Nasser]

danish iftikhar wrote:
> 
>    Well , i tried to use the above commands and was able to download
> successfully . But after i set break point and do continue , everything
> seems to hang .
> Any guesses what is going wrong now .
> the rdiromatzero command for EP7211 board should be set at 0 or 1 ??
> i am using insight 5.0 .
> 
>   do we need to specifically download some program for reset and all those
> things which Grant has told .
> 

I don't have a Jeeni target, so Grant is the person who can help you with that.

I would try "set rdiromatzero true" as it is a quick test.

Another thing you can do is to turn on Grant's RDI trace facility:

Something like

maintenance rdilogfile /dev/tty
maintenance rdilogenable on

Would print the message exchange between GDB and the target.

Do this after the load or you will have too many messages!


BTW, your program may have been linked with the wrong load address.
What is the value of the PC  (P/x $pc) after the load?


-- 
Fernando Nasser
Red Hat - Toronto                       E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9
From taylor@cygnus.com Tue Nov 21 12:38:00 2000
From: David Taylor <taylor@cygnus.com>
To: gdb@sourceware.cygnus.com
Cc: gdb-patches@sourceware.cygnus.com
Subject: pathmap (again)
Date: Tue, 21 Nov 2000 12:38:00 -0000
Message-id: <200011212037.PAA22391@texas.cygnus.com>
X-SW-Source: 2000-11/msg00222.html
Content-length: 1370

Okay, I don't think there was complete agreement on the syntax and the
semantics, but here's a stab at what I think was agreeable to most...

Proposed Interface:

    pathmap add <from> <to>

	append a mapping from directory <from> to directory <to>
	to the current list of mappings.

    pathmap delete <optional-list>

	delete the mappings indexed by <optional-list> from the
	list of known mappings.  All subsequent mappings move up
	the list.  (For example, if you delete mapping 2, then mapping
	3 becomes mapping 2, mapping 4 becomes mapping 3, and so on.)

    pathmap list <optional-list>

	list the specified mappings.  If no list is given, all
	mappings are listed.

and potentially:

    pathmap insert <index> <from> <to>

	As for 'pathmap add', but insert the mapping immediately after
	mapping <index>.  All subsequent mappings move down the list.
	If <index> is zero, then the mapping is inserted before the
	first mapping.

Where:

    <from> and <to> are directory path prefixes 

    <optional-list> is a list in the same format as for the
		breakpoint commands

    <index> is a non negative integer

And the mappings are not regular expressions -- that is left as a
potential enhancement for the future.  Also, I'm unconvinced of the
need for the "pathmap insert" functionality.

Comments?

David
--
David Taylor
taylor@redhat.com, taylor@cygnus.com
From fnasser@cygnus.com Tue Nov 21 13:39:00 2000
From: Fernando Nasser <fnasser@cygnus.com>
To: David Taylor <taylor@cygnus.com>
Cc: gdb@sourceware.cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: Re: pathmap (again)
Date: Tue, 21 Nov 2000 13:39:00 -0000
Message-id: <3A1AEBA8.5EA780AF@cygnus.com>
References: <200011212037.PAA22391@texas.cygnus.com>
X-SW-Source: 2000-11/msg00223.html
Content-length: 2492

Well, I like it this way.  It does not hurt the CLI language at all
so if you are looking for an "approval in principle" or something like that
consider it given.  I will not pest you with requests to change the command
interface anymore :-)

I can only answer for the CLI aspects though.  But I understood that people 
liked the idea of having this around, so if I did not misunderstood I believe
everybody is sort of waiting for the patch already.

The "insert" operation is interesting.  I think J.T. gave a good example of
a situation where it can be useful.  But I guess it is a simple thing to add
at any time, so we may test the concept by initially not providing it and
seeing if someone asks for it (out of a personal need) or even send a patch.

IMO you should go ahead with this and submit a patch.

Fernando


David Taylor wrote:
> 
> Okay, I don't think there was complete agreement on the syntax and the
> semantics, but here's a stab at what I think was agreeable to most...
> 
> Proposed Interface:
> 
>     pathmap add <from> <to>
> 
>         append a mapping from directory <from> to directory <to>
>         to the current list of mappings.
> 
>     pathmap delete <optional-list>
> 
>         delete the mappings indexed by <optional-list> from the
>         list of known mappings.  All subsequent mappings move up
>         the list.  (For example, if you delete mapping 2, then mapping
>         3 becomes mapping 2, mapping 4 becomes mapping 3, and so on.)
> 
>     pathmap list <optional-list>
> 
>         list the specified mappings.  If no list is given, all
>         mappings are listed.
> 
> and potentially:
> 
>     pathmap insert <index> <from> <to>
> 
>         As for 'pathmap add', but insert the mapping immediately after
>         mapping <index>.  All subsequent mappings move down the list.
>         If <index> is zero, then the mapping is inserted before the
>         first mapping.
> 
> Where:
> 
>     <from> and <to> are directory path prefixes
> 
>     <optional-list> is a list in the same format as for the
>                 breakpoint commands
> 
>     <index> is a non negative integer
> 
> And the mappings are not regular expressions -- that is left as a
> potential enhancement for the future.  Also, I'm unconvinced of the
> need for the "pathmap insert" functionality.
> 
> Comments?
> 


-- 
Fernando Nasser
Red Hat - Toronto                       E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9
From jtc@redback.com Tue Nov 21 17:06:00 2000
From: jtc@redback.com (J.T. Conklin)
To: Eli Zaretskii <eliz@is.elta.co.il>
Cc: gdb@sourceware.cygnus.com
Subject: Re: memory region documentation
Date: Tue, 21 Nov 2000 17:06:00 -0000
Message-id: <5mem04rf23.fsf@jtc.redback.com>
References: <5mg0ku2r9l.fsf@jtc.redback.com> <200011151126.GAA03721@indy.delorie.com> <5mpujvhh52.fsf@jtc.redback.com> <200011162001.PAA04807@indy.delorie.com>
X-SW-Source: 2000-11/msg00224.html
Content-length: 883

>>>>> "Eli" == Eli Zaretskii <eliz@delorie.com> writes:
>> However, this exercise has reminded me why I'm a programmer and not a
>> tech writer.

Eli> Actually, what you wrote was very good; the comments I had were pretty
Eli> much minor.

Thanks, but I stand by my comment --- You didn't see what went into
that draft.  I spent a lot of time writing (and re-writing) it until
it reflected what I wanted to say.

>> Can you tell me where you'd like me to put this chapter?  I assume
>> it's a chapter, since it doesn't seem to be a good fit into any of
>> the existing chapters --- especially if we start adding more varied
>> attributes.

Eli> It looks like between "Native Debugging" and "Support Libraries"
Eli> would be a good place.

Eh?  Those chapters are in the internals document, this is intended to
be user documentation.

        --jtc

-- 
J.T. Conklin
RedBack Networks
From d_iftikhar@hotmail.com Wed Nov 22 00:08:00 2000
From: "danish iftikhar" <d_iftikhar@hotmail.com>
To: gdb@sourceware.cygnus.com
Subject: GDB & Jeeni
Date: Wed, 22 Nov 2000 00:08:00 -0000
Message-id: <F2516byoxxSQWBLYu7A00001552@hotmail.com>
X-SW-Source: 2000-11/msg00225.html
Content-length: 4680

Hi
i am still not able to execute the program on the target boeard .
As soon as i give 'cont' , everything goes for a toss .
i am also not able to single step it ..when i give info target command , it
says "Target does not support single stepping " .
But , when i tried by using "stepi" instruction it at once moved into some
"warm-reset" assembly code ..& from there to "start" code and startted an
endless loop there .
i think that it is not able to initialise even ..
any guesses where the problem may be .
i enabled the rdilogfile , but i could'nt figure out anything from it ..
i am attaching the log file , hoping some of u may help me in this regard .

thanks
danish.

WITH rdiromatzero 1 :

ADP log file opened at Wed Nov 22 16:40:10 2000

tx: [T=0 L=25] 01 fd fc 01 05 00 01 00 00 00 00 00 ff ff ff ff ff ff ff ff
ff 00 00 02 00
R=00010005 H->T CI_HADP:  ADP_CPUread ff 00020000
rx: [T=0 L=28] 01 fd fd 01 05 00 01 80 00 00 00 00 ff ff ff ff ff ff ff ff
00 00 00 00 d3 00 00 00
R=80010005 H<-T CI_HADP:  ADP_CPUread 00000000 000000d3
tx: [T=0 L=25] 01 fe fd 01 05 00 01 00 00 00 00 00 ff ff ff ff ff ff ff ff
ff 00 08 00 00
R=00010005 H->T CI_HADP:  ADP_CPUread ff 00000800
rx: [T=0 L=28] 01 fe fe 01 05 00 01 80 00 00 00 00 ff ff ff ff ff ff ff ff
00 00 00 00 60 18 00 00
R=80010005 H<-T CI_HADP:  ADP_CPUread 00000000 00001860
tx: [T=0 L=28] 01 ff fe 01 03 00 01 00 00 00 00 00 ff ff ff ff ff ff ff ff
60 80 00 00 04 00 00 00
R=00010003 H->T CI_HADP:  ADP_Read 00008060 00000004
rx: [T=0 L=32] 01 ff ff 01 03 00 01 80 00 00 00 00 ff ff ff ff ff ff ff ff
00 00 00 00 00 00 00 00 00 70 0f e1
R=80010003 H<-T CI_HADP:  ADP_Read 00000000 00000000 e10f7000
tx: [T=0 L=25] 01 00 ff 01 05 00 01 00 00 00 00 00 ff ff ff ff ff ff ff ff
ff 00 20 00 00
R=00010005 H->T CI_HADP:  ADP_CPUread ff 00002000
rx: [T=0 L=28] 01 00 00 01 05 00 01 80 00 00 00 00 ff ff ff ff ff ff ff ff
00 00 00 00 54 18 00 00
R=80010005 H<-T CI_HADP:  ADP_CPUread 00000000 00001854
tx: [T=0 L=29] 01 01 00 01 09 00 01 00 00 00 00 00 ff ff ff ff ff ff ff ff
8c 85 00 00 00 00 00 00 00
R=00010009 H->T CI_HADP:  ADP_SetBreak 0000858c 00000000 00000000
rx: [T=0 L=36] 01 01 01 01 09 00 01 80 00 00 00 00 ff ff ff ff ff ff ff ff
00 00 00 00 78 ec 03 00 74 fe 1e 00 dc 98 00 00
R=80010009 H<-T CI_HADP:  ADP_SetBreak 00000000 0003ec78 001efe74 000098dc
tx: [T=0 L=24] 01 02 01 01 0d 00 01 00 00 00 00 00 ff ff ff ff ff ff ff ff
00 00 00 00
R=0001000d H->T CI_HADP:  ADP_Execute 00000000
rx: [T=0 L=24] 01 02 02 01 0d 00 01 80 00 00 00 00 ff ff ff ff ff ff ff ff
00 00 00 00
R=8001000d H<-T CI_HADP:  ADP_Execute 00000000


WITH rdiromatzero 0 :

ADP log file opened at Wed Nov 22 16:55:43 2000

tx: [T=0 L=25] 01 fd fc 01 05 00 01 00 00 00 00 00 ff ff ff ff ff ff ff ff
ff 00 00 02 00
R=00010005 H->T CI_HADP:  ADP_CPUread ff 00020000
rx: [T=0 L=28] 01 fd fd 01 05 00 01 80 00 00 00 00 ff ff ff ff ff ff ff ff
00 00 00 00 d3 00 00 00
R=80010005 H<-T CI_HADP:  ADP_CPUread 00000000 000000d3
tx: [T=0 L=25] 01 fe fd 01 05 00 01 00 00 00 00 00 ff ff ff ff ff ff ff ff
ff 00 08 00 00
R=00010005 H->T CI_HADP:  ADP_CPUread ff 00000800
rx: [T=0 L=28] 01 fe fe 01 05 00 01 80 00 00 00 00 ff ff ff ff ff ff ff ff
00 00 00 00 60 18 00 00
R=80010005 H<-T CI_HADP:  ADP_CPUread 00000000 00001860
tx: [T=0 L=28] 01 ff fe 01 03 00 01 00 00 00 00 00 ff ff ff ff ff ff ff ff
60 80 00 00 04 00 00 00
R=00010003 H->T CI_HADP:  ADP_Read 00008060 00000004
rx: [T=0 L=32] 01 ff ff 01 03 00 01 80 00 00 00 00 ff ff ff ff ff ff ff ff
00 00 00 00 00 00 00 00 00 70 0f e1
R=80010003 H<-T CI_HADP:  ADP_Read 00000000 00000000 e10f7000
tx: [T=0 L=25] 01 00 ff 01 05 00 01 00 00 00 00 00 ff ff ff ff ff ff ff ff
ff 00 20 00 00
R=00010005 H->T CI_HADP:  ADP_CPUread ff 00002000
rx: [T=0 L=28] 01 00 00 01 05 00 01 80 00 00 00 00 ff ff ff ff ff ff ff ff
00 00 00 00 54 18 00 00
R=80010005 H<-T CI_HADP:  ADP_CPUread 00000000 00001854
tx: [T=0 L=29] 01 01 00 01 09 00 01 00 00 00 00 00 ff ff ff ff ff ff ff ff
8c 85 00 00 00 00 00 00 00
R=00010009 H->T CI_HADP:  ADP_SetBreak 0000858c 00000000 00000000
rx: [T=0 L=36] 01 01 01 01 09 00 01 80 00 00 00 00 ff ff ff ff ff ff ff ff
00 00 00 00 78 ec 03 00 74 fe 1e 00 dc 98 00 00
R=80010009 H<-T CI_HADP:  ADP_SetBreak 00000000 0003ec78 001efe74 000098dc
tx: [T=0 L=24] 01 02 01 01 0d 00 01 00 00 00 00 00 ff ff ff ff ff ff ff ff
00 00 00 00
R=0001000d H->T CI_HADP:  ADP_Execute 00000000
rx: [T=0 L=24] 01 02 02 01 0d 00 01 80 00 00 00 00 ff ff ff ff ff ff ff ff
00 00 00 00
R=8001000d H<-T CI_HADP:  ADP_Execute 00000000






_____________________________________________________________________________________
Get more from the Web.  FREE MSN Explorer download : http://explorer.msn.com

Re: Jeeni & ARM720T with GDB

[Fernando Nasser]

The sequence of commands you should use is:

file <exec>
target rdi e=....
load
break <somewhere>
cont


Don't use the load command argument.

Fernando


danish iftikhar wrote:
> 
> Hi
>    I am trying to use Jeeni EMbedded Ice to connect from my linux host
> running GDB to Cirrus Logic EP7211 board .
> The board uses ARM720T processor , due to which i have set the same
> configuration in Jeeni .
> Then i tried to connect to target by using target rdi e=IP_ADDR ;
> ( as i tried using ethernet interface ) . It then said connected to target
> ..something..something .
> But when i give the load (filename) , it does'nt do anything ..
> once it said "you can't do that when your target is exec" , i gave the
> target rdi command again and tried to download & then it hanged .
> 
> Can anybody explain what is happening...do i need to do anything else for
> downloading the program .
> 
> PS: i have set the appropriate endianness also .
> 
> regards
> danish.
> 
> _________________________________________________________________________
> Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com .
> 
> Share information about yourself, create your own public profile at
> http://profiles.msn.com .

-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9
From mleibowi@crystal.cirrus.com Mon Nov 20 09:01:00 2000
From: Michael Leibowitz <mleibowi@crystal.cirrus.com>
To: Fernando Nasser <fnasser@cygnus.com>
Cc: danish iftikhar <d_iftikhar@hotmail.com>, gdb@sourceware.cygnus.com
Subject: Re: Jeeni & ARM720T with GDB
Date: Mon, 20 Nov 2000 09:01:00 -0000
Message-id: <20001120110414.B23797@spanky>
References: <F262O6hm8Ua8d9Ee4za00002d74@hotmail.com> <3A1955CE.2A4280C8@cygnus.com>
X-SW-Source: 2000-11/msg00203.html
Content-length: 502

When I try that, I get an error message:

Continuing.
RDI_execute: a miscellaneous type of error

Program received signal SIGTERM, Terminated.
?? () at setup.S:4
4		B	Reset_Handler
Current language:  auto; currently asm

using gdb 5.0 (insight w/ -nw) and 7211 eval board.

Any ideas?

On Mon, 20 Nov 2000 10:48:14 Fernando Nasser wrote:
> The sequence of commands you should use is:
> 
> file <exec>
> target rdi e=....
> load
> break <somewhere>
> cont
> 
> 
> Don't use the load command argument.

Re: Jeeni & ARM720T with GDB

[Fernando Nasser]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 9863 bytes --]

Michael Leibowitz wrote:
> 
> When I try that, I get an error message:
> 
> Continuing.
> RDI_execute: a miscellaneous type of error
> 
> Program received signal SIGTERM, Terminated.
> ?? () at setup.S:4
> 4               B       Reset_Handler
> Current language:  auto; currently asm
> 
> using gdb 5.0 (insight w/ -nw) and 7211 eval board.
> 
> Any ideas?
> 

It can be the way you compiled/linked your program or a series of
other reasons.  There is not much information above.
Maybe you should post pieces of console output with the relevant 
information (the output of "gcc -v", your compilation command and 
any messages printed by gcc, etc).

BTW, which host are you running gdb on? Which OS version, libraries...

If I am not mistaken, there were a series of fixes and improvements
to GDB RDI after 5.0 came out.  I am not sure that they can make any
difference to your case, but maybe you should consider switching to
more recent sources.

Fernando



> On Mon, 20 Nov 2000 10:48:14 Fernando Nasser wrote:
> > The sequence of commands you should use is:
> >
> > file <exec>
> > target rdi e=....
> > load
> > break <somewhere>
> > cont
> >
> >
> > Don't use the load command argument.

-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9
From grante@visi.com Mon Nov 20 14:25:00 2000
From: Grant Edwards <grante@visi.com>
To: Fernando Nasser <fnasser@cygnus.com>
Cc: danish iftikhar <d_iftikhar@hotmail.com>, gdb@sourceware.cygnus.com
Subject: Re: Jeeni & ARM720T with GDB
Date: Mon, 20 Nov 2000 14:25:00 -0000
Message-id: <20001120162802.A11863@visi.com>
References: <F262O6hm8Ua8d9Ee4za00002d74@hotmail.com> <3A1955CE.2A4280C8@cygnus.com>
X-SW-Source: 2000-11/msg00205.html
Content-length: 755

On Mon, Nov 20, 2000 at 04:48:14PM +0000, Fernando Nasser wrote:
> The sequence of commands you should use is:
> 
> file <exec>
> target rdi e=....
> load
> break <somewhere>
> cont
> 
> Don't use the load command argument.

Why not?  

It works fine for me.  The macro I use to load an ELF object
file is:

define reload
  resetcpu
  delete
  symbol-file 
  symbol-file $arg0
  load $arg0
  break *0x00
  break *0x04
  break *0x08
  break *0x0c
  break *0x10
  break *0x14
  # IRQ at 0x18 is used
  break *0x1c
end

After a "reload" then I do "cont" after optionally setting more
breakpoints.

The "resetcpu" command at the top is another macro that resets
a bunch of peripheral chips and puts them into a known state.

-- 
Grant Edwards
grante@visi.com
From grante@visi.com Mon Nov 20 14:27:00 2000
From: Grant Edwards <grante@visi.com>
To: Michael Leibowitz <mleibowi@crystal.cirrus.com>
Cc: Fernando Nasser <fnasser@cygnus.com>, danish iftikhar <d_iftikhar@hotmail.com>, gdb@sourceware.cygnus.com
Subject: Re: Jeeni & ARM720T with GDB
Date: Mon, 20 Nov 2000 14:27:00 -0000
Message-id: <20001120162925.B11863@visi.com>
References: <F262O6hm8Ua8d9Ee4za00002d74@hotmail.com> <3A1955CE.2A4280C8@cygnus.com> <20001120110414.B23797@spanky>
X-SW-Source: 2000-11/msg00206.html
Content-length: 436

On Mon, Nov 20, 2000 at 11:04:14AM -0600, Michael Leibowitz wrote:

> When I try that, I get an error message:
> 
> Continuing.
> RDI_execute: a miscellaneous type of error
> 
> Program received signal SIGTERM, Terminated.
> ?? () at setup.S:4
> 4		B	Reset_Handler
> Current language:  auto; currently asm
> 
> using gdb 5.0 (insight w/ -nw) and 7211 eval board.
> 
> Any ideas?

The "load" works OK?

-- 
Grant Edwards
grante@visi.com
From grante@visi.com Mon Nov 20 14:28:00 2000
From: Grant Edwards <grante@visi.com>
To: Fernando Nasser <fnasser@cygnus.com>
Cc: mleibowi@crystal.cirrus.com, danish iftikhar <d_iftikhar@hotmail.com>, gdb@sourceware.cygnus.com
Subject: Re: Jeeni & ARM720T with GDB
Date: Mon, 20 Nov 2000 14:28:00 -0000
Message-id: <20001120163048.C11863@visi.com>
References: <F262O6hm8Ua8d9Ee4za00002d74@hotmail.com> <3A1955CE.2A4280C8@cygnus.com> <20001120110414.B23797@spanky> <3A195CAA.ED939698@cygnus.com>
X-SW-Source: 2000-11/msg00207.html
Content-length: 814

On Mon, Nov 20, 2000 at 05:17:30PM +0000, Fernando Nasser wrote:

> It can be the way you compiled/linked your program or a series of
> other reasons.  There is not much information above.
> Maybe you should post pieces of console output with the relevant 
> information (the output of "gcc -v", your compilation command and 
> any messages printed by gcc, etc).
> 
> BTW, which host are you running gdb on? Which OS version, libraries...
> 
> If I am not mistaken, there were a series of fixes and improvements
> to GDB RDI after 5.0 came out.  I am not sure that they can make any
> difference to your case, but maybe you should consider switching to
> more recent sources.

Most of the changes had to do with Insight GUI issues, but it
couldn't hurt to use a recent snapshot.

-- 
Grant Edwards
grante@visi.com
From Stephane.Carrez@worldnet.fr Mon Nov 20 14:46:00 2000
From: Stephane Carrez <Stephane.Carrez@worldnet.fr>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: Fernando Nasser <fnasser@cygnus.com>, gdb@sources.redhat.com
Subject: Re: RFC: Components
Date: Mon, 20 Nov 2000 14:46:00 -0000
Message-id: <3A19B7F2.665348DC@worldnet.fr>
References: <3A0B3556.510B850A@cygnus.com> <3A19491E.E2FDB7FB@cygnus.com>
X-SW-Source: 2000-11/msg00208.html
Content-length: 3730

Hi!

Andrew Cagney a écrit :
> 
> Fernando Nasser wrote:
> >
> > We got a submission from a contributor that would like to add the following
> > facility to GDB, which can be useful when debugging Operating Systems.
> >
> >         An operating system can comprise of several components, each of them
> >         linked separately. When doing system debug, the symbols of all the
> >         OS components are loaded into GDB. Once loaded, GDB has several symbol
> >         files that it uses to search for symbols and debugging information.
> 
> (Like J.T. I'm not also sure about the word component)

So do I. But I had no better name to propose/use...


> 
> I think this can be broken down into several problems/issues.
> 
> GDB is (eventually :-) going to get support for multiple
> processes/actors/....  Such proceses can probably be categorized into
> two classes:
> 
>         o       VM
> 
>                 Where separate processes have
>                 independant address spaces.
> 
>                 Examples include most modern
>                 OS's along with UNIX and Linux.
> 
>         o       no-vm
> 
>                 Where separate processes share
>                 a common address space.
> 
>                 Examples of this would include
>                 uLinux and MINIX/68k.
> 
> I think an extention to GDB's SAL (linespec) syntax needs to be clearly
> defined so that it will be possible to identify the process that a
> symbol belongs to.  The exact syntax will likely need more thought
> although the proposal is probably a good starting point.  It is more
> natural to use the target OS's process names and that is a departure
> from the current GDB convention which, in the case of threads, adopted
> arbitrary internal numbers.

Yes, but using the target OS's process name is more difficult. The so-called
component may not refer to a process. It can of course, but it can also
represent some code that is loaded.

Doing that requires more changes in Gdb too, since this is target specific.
We also need a way to attach some target specific name to the symtab.


> 
> Depending on the kernel, it may be possible to unwind a stack back
> through the user->kernel system call.  On such systems, the stack dump
> should clearly identify the process that the stack frames belong to.  On
> OSs that use an indirect call to get into the kernel, this is pretty
> much a no-brainer.  On OSs that context switch on entry into the kernel,
> this is more complex  Something a bit like the code to unwind past a
> single handler would be needed.

Stack unwinding does not work in gdb when you cross a trap/exception handler
It would be good to teach that in Gdb. But it's not easy...


> 
> At a more general level, I don't have any real reservations about the
> proposed functionality (I've encountered a number of embedded systems
> where I've had to use smoke and mirrors to get around just this
> problem).  The concerns I have are related to the details of the
> implementation and how well the actual changes fit in with the broad
> strategy of evolving GDB into a multi-processor debugger.
> 
>         Andrew

Using the basename of the symbol file was very simple. I guess it's possible
to use another transformation operation that produces such short printable string.


	Stephane

-----------------------------------------------------------------------
         Home                               Office
E-mail: stcarrez@worldnet.fr               Stephane.Carrez@sun.com
WWW:    http://home.worldnet.fr/stcarrez   http://www.sun.com
Mail:   17, rue Foucher Lepelletier        6, avenue Gustave Eiffel
        92130 Issy Les Moulineaux          78182 Saint Quentin en Yvelines
        France
From mleibowi@crystal.cirrus.com Mon Nov 20 15:34:00 2000
From: Michael Leibowitz <mleibowi@crystal.cirrus.com>
To: Grant Edwards <grante@visi.com>
Cc: Michael Leibowitz <mleibowi@crystal.cirrus.com>, Fernando Nasser <fnasser@cygnus.com>, danish iftikhar <d_iftikhar@hotmail.com>, gdb@sourceware.cygnus.com
Subject: Re: Jeeni & ARM720T with GDB
Date: Mon, 20 Nov 2000 15:34:00 -0000
Message-id: <20001120173821.B24131@spanky>
References: <F262O6hm8Ua8d9Ee4za00002d74@hotmail.com> <3A1955CE.2A4280C8@cygnus.com> <20001120110414.B23797@spanky> <20001120162925.B11863@visi.com>
X-SW-Source: 2000-11/msg00209.html
Content-length: 150

On Mon, 20 Nov 2000 16:29:25 Grant Edwards wrote:
> On Mon, Nov 20, 2000 at 11:04:14AM -0600, Michael Leibowitz wrote:

> The "load" works OK?

Yeah

Re: Jeeni & ARM720T with GDB

[Grant Edwards]

On Mon, Nov 20, 2000 at 05:38:21PM -0600, Michael Leibowitz wrote:

> > The "load" works OK?
> 
> Yeah

Do the load addresses and start addresses printed by the "load"
command look right?

-- 
Grant Edwards
grante@visi.com
From hjl@valinux.com Mon Nov 20 15:59:00 2000
From: "H . J . Lu" <hjl@valinux.com>
To: binutils@sourceware.cygnus.com
Cc: GDB <gdb@sourceware.cygnus.com>
Subject: Patches to change ELFOSABI_MONTEREY to ELFOSABI_AIX.
Date: Mon, 20 Nov 2000 15:59:00 -0000
Message-id: <20001120155917.A15923@valinux.com>
X-SW-Source: 2000-11/msg00211.html
Content-length: 4665

ELFOSABI_MONTEREY has been replaced by ELFOSABI_AIX. I have checked in
patches to change all ELFOSABI_MONTEREY to ELFOSABI_AIX.

BTW, ELFOSABI_NONE, ELFOSABI_HPUX, ELFOSABI_NETBSD, ELFOSABI_LINUX,
ELFOSABI_HURD, ELFOSABI_SOLARIS, ELFOSABI_AIX, ELFOSABI_IRIX,
ELFOSABI_FREEBSD, ELFOSABI_TRU64, ELFOSABI_MODESTO and ELFOSABI_OPENBSD
will be moved from psABI to gABI. The first 128 entries in EI_OSABI
will be reserved for gABI and the last 28 entries will be for psABI. I
saw

#define ELFOSABI_STANDALONE 255 /* Standalone (embedded) application */
#define ELFOSABI_ARM   97               /* ARM */

in include/elf/common.h. They will violate the new gABI.

BTW, the EI_OSABI byte is used to tell how to interpret those fields
and values which are not defined by gABI nor psABI. It is not to tell
on which platform the binary is targeted. I am not sure if ELFOSABI_ARM
and ELFOSABI_STANDALONE are proper uses for this field. Should we fix
them?


-- 
H.J. Lu (hjl@valinux.com)
---
Index: binutils/ChangeLog
===================================================================
RCS file: /cvs/src/src/binutils/ChangeLog,v
retrieving revision 1.222
diff -u -p -r1.222 ChangeLog
--- ChangeLog	2000/11/19 20:57:42	1.222
+++ ChangeLog	2000/11/20 23:39:37
@@ -1,3 +1,8 @@
+2000-11-20  H.J. Lu  <hjl@gnu.org>
+
+	* readelf.c (get_osabi_name): Change ELFOSABI_MONTEREY to
+	ELFOSABI_AIX.
+
 2000-11-17  Richard Henderson  <rth@redhat.com>
 
 	* readelf.c (display_debug_lines): Adjust last change to
Index: binutils/readelf.c
===================================================================
RCS file: /cvs/src/src/binutils/readelf.c,v
retrieving revision 1.72
diff -u -p -r1.72 readelf.c
--- readelf.c	2000/11/19 20:57:42	1.72
+++ readelf.c	2000/11/20 23:39:45
@@ -2087,7 +2087,7 @@ get_osabi_name (osabi)
     case ELFOSABI_LINUX:      return _("UNIX - Linux");
     case ELFOSABI_HURD:       return _("GNU/Hurd");
     case ELFOSABI_SOLARIS:    return _("UNIX - Solaris");
-    case ELFOSABI_MONTEREY:   return _("UNIX - Monterey");
+    case ELFOSABI_AIX:        return _("UNIX - AIX");
     case ELFOSABI_IRIX:       return _("UNIX - IRIX");
     case ELFOSABI_FREEBSD:    return _("UNIX - FreeBSD");
     case ELFOSABI_TRU64:      return _("UNIX - TRU64");
Index: gdb/ChangeLog
===================================================================
RCS file: /cvs/src/src/gdb/ChangeLog,v
retrieving revision 1.789
diff -u -p -r1.789 ChangeLog
--- ChangeLog	2000/11/20 20:33:52	1.789
+++ ChangeLog	2000/11/20 23:39:52
@@ -1,3 +1,8 @@
+2000-11-20  H.J. Lu  <hjl@gnu.org>
+
+	* ia64-tdep.c (gdbarch_tdep): Change reference from
+	ELFOSABI_MONTEREY to ELFOSABI_AIX.
+
 2000-11-20  Peter Schauer  <pes@regent.e-technik.tu-muenchen.de>
 
 	* c-valprint.c (print_function_pointer_address):  New function
Index: gdb/ia64-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/ia64-tdep.c,v
retrieving revision 1.10
diff -u -p -r1.10 ia64-tdep.c
--- ia64-tdep.c	2000/11/08 04:12:40	1.10
+++ ia64-tdep.c	2000/11/20 23:39:55
@@ -226,7 +226,7 @@ struct frame_extra_info
 struct gdbarch_tdep
   {
     int os_ident;	/* From the ELF header, one of the ELFOSABI_
-                           constants: ELFOSABI_LINUX, ELFOSABI_MONTEREY,
+                           constants: ELFOSABI_LINUX, ELFOSABI_AIX,
 			   etc. */
     CORE_ADDR (*sigcontext_register_address) (CORE_ADDR, int);
     			/* OS specific function which, given a frame address
Index: include/elf/ChangeLog
===================================================================
RCS file: /cvs/src/src/include/elf/ChangeLog,v
retrieving revision 1.71
diff -u -p -r1.71 ChangeLog
--- ChangeLog	2000/11/16 22:48:14	1.71
+++ ChangeLog	2000/11/20 23:39:58
@@ -1,3 +1,8 @@
+2000-11-20  H.J. Lu  <hjl@gnu.org>
+
+	* common.h (ELFOSABI_MONTEREY): Renamed to ...
+	(ELFOSABI_AIX): This.
+
 2000-11-16  Richard Henderson  <rth@redhat.com>
 
 	Update relocations per August psABI docs.
Index: include/elf/common.h
===================================================================
RCS file: /cvs/src/src/include/elf/common.h,v
retrieving revision 1.23
diff -u -p -r1.23 common.h
--- common.h	2000/07/20 15:44:56	1.23
+++ common.h	2000/11/20 23:39:59
@@ -64,7 +64,7 @@ Foundation, Inc., 59 Temple Place - Suit
 #define ELFOSABI_LINUX  3       /* GNU/Linux */
 #define ELFOSABI_HURD   4       /* GNU/Hurd */
 #define ELFOSABI_SOLARIS 6      /* Solaris */
-#define ELFOSABI_MONTEREY 7     /* Monterey */
+#define ELFOSABI_AIX    7       /* AIX */
 #define ELFOSABI_IRIX   8       /* IRIX */
 #define ELFOSABI_FREEBSD 9      /* FreeBSD */
 #define ELFOSABI_TRU64  10      /* TRU64 UNIX */
From Fabrice_Gautier@sdesigns.com Mon Nov 20 16:12:00 2000
From: Fabrice Gautier <Fabrice_Gautier@sdesigns.com>
To: "'insight@sources.redhat.com'" <insight@sources.redhat.com>
Cc: "GDB (E-mail)" <gdb@sourceware.cygnus.com>
Subject: RE: Buil problem
Date: Mon, 20 Nov 2000 16:12:00 -0000
Message-id: <B1F6452C89AFD411AE0800A0CC734C23015032@EMAIL1>
X-SW-Source: 2000-11/msg00212.html
Content-length: 1283

Hi,

I think i found why it failed. The following patch seems to have a good
effect:

--- gdb/linespec.c~ Fri Nov 10 15:02:56 2000
+++ gdb/linespec.c  Mon Nov 20 15:13:43 2000
@@ -37,7 +37,7 @@

 extern char *operator_chars (char *, char **);

-extern char *no_symtab_msg;
+extern char no_symtab_msg[];

 /* Prototypes for local functions */

The no_symtab_msg is defined as char no_symtab_msg[] in an other file, and
not as 
char *no_symtab_msg.

I think there might be a few other place where this mistake could have been
made but i didn't saw any around that one.

By the way this seems more like a gdb thing than a insight thing, but it was
somehow triggered when using the gui.

Thanks

> -----Original Message-----
> From: Fabrice Gautier [ mailto:Fabrice_Gautier@sdesigns.com ]
> Sent: Monday, November 20, 2000 2:19 PM
> To: 'insight@sources.redhat.com'
> Subject: RE: Buil problem
> 
> 
> Hi,
> 
> Attached is a call stack I obtained with gdb,
> 
> If it helps find the problem.
> 
> Thanks
> 
> > -----Original Message-----
> > From: Fabrice Gautier [ mailto:Fabrice_Gautier@sdesigns.com ]
> > Subject: RE: Buil problem
> > 
> > 
> > Using the latest snapshot i didn't have any problem building. 
> > But insight
> > still crash unless I use -nw.
> > 
> > Thanks
>  
> 
> 
From kevinb@cygnus.com Mon Nov 20 16:26:00 2000
From: Kevin Buettner <kevinb@cygnus.com>
To: "H . J . Lu" <hjl@valinux.com>, binutils@sourceware.cygnus.com
Cc: GDB <gdb@sourceware.cygnus.com>
Subject: Re: Patches to change ELFOSABI_MONTEREY to ELFOSABI_AIX.
Date: Mon, 20 Nov 2000 16:26:00 -0000
Message-id: <1001121002613.ZM18358@ocotillo.lan>
References: <20001120155917.A15923@valinux.com> <hjl@valinux.com>
X-SW-Source: 2000-11/msg00213.html
Content-length: 377

On Nov 20,  3:59pm, H . J . Lu wrote:

> BTW, the EI_OSABI byte is used to tell how to interpret those fields
> and values which are not defined by gABI nor psABI. It is not to tell
> on which platform the binary is targeted. [...]

What is the proper method for determining the target platform?

(I know how to do it if it's linked against glibc, but not
otherwise...)

Kevin
From fnasser@cygnus.com Mon Nov 20 16:39:00 2000
From: Fernando Nasser <fnasser@cygnus.com>
To: Fabrice Gautier <Fabrice_Gautier@sdesigns.com>
Cc: "'insight@sources.redhat.com'" <insight@sources.redhat.com>, "GDB (E-mail)" <gdb@sourceware.cygnus.com>
Subject: Re: Buil problem
Date: Mon, 20 Nov 2000 16:39:00 -0000
Message-id: <3A19C413.519904F1@cygnus.com>
References: <B1F6452C89AFD411AE0800A0CC734C23015032@EMAIL1>
X-SW-Source: 2000-11/msg00214.html
Content-length: 1992

This fix is already in the current sources.  It was broken for a few hours
and it is very unfortunate you've got it during that window of time.

I inadvertently broke this when splitting a file so at least you have
someone to blame ;-)

BTW, when using the latest sources from cvs and encountering a build problem,
always try to do a "cvs update".  Any glitch like this is normally fixed
quickly.

Sorry about all the trouble.

Fernando



Fabrice Gautier wrote:
> 
> Hi,
> 
> I think i found why it failed. The following patch seems to have a good
> effect:
> 
> --- gdb/linespec.c~ Fri Nov 10 15:02:56 2000
> +++ gdb/linespec.c  Mon Nov 20 15:13:43 2000
> @@ -37,7 +37,7 @@
> 
>  extern char *operator_chars (char *, char **);
> 
> -extern char *no_symtab_msg;
> +extern char no_symtab_msg[];
> 
>  /* Prototypes for local functions */
> 
> The no_symtab_msg is defined as char no_symtab_msg[] in an other file, and
> not as
> char *no_symtab_msg.
> 
> I think there might be a few other place where this mistake could have been
> made but i didn't saw any around that one.
> 
> By the way this seems more like a gdb thing than a insight thing, but it was
> somehow triggered when using the gui.
> 
> Thanks
> 
> > -----Original Message-----
> > From: Fabrice Gautier [ mailto:Fabrice_Gautier@sdesigns.com ]
> > Sent: Monday, November 20, 2000 2:19 PM
> > To: 'insight@sources.redhat.com'
> > Subject: RE: Buil problem
> >
> >
> > Hi,
> >
> > Attached is a call stack I obtained with gdb,
> >
> > If it helps find the problem.
> >
> > Thanks
> >
> > > -----Original Message-----
> > > From: Fabrice Gautier [ mailto:Fabrice_Gautier@sdesigns.com ]
> > > Subject: RE: Buil problem
> > >
> > >
> > > Using the latest snapshot i didn't have any problem building.
> > > But insight
> > > still crash unless I use -nw.
> > >
> > > Thanks
> >
> >
> >

-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9
From hjl@valinux.com Mon Nov 20 16:39:00 2000
From: "H . J . Lu" <hjl@valinux.com>
To: Kevin Buettner <kevinb@cygnus.com>
Cc: binutils@sourceware.cygnus.com, GDB <gdb@sourceware.cygnus.com>
Subject: Re: Patches to change ELFOSABI_MONTEREY to ELFOSABI_AIX.
Date: Mon, 20 Nov 2000 16:39:00 -0000
Message-id: <20001120163940.B17290@valinux.com>
References: <20001120155917.A15923@valinux.com> <hjl@valinux.com> <1001121002613.ZM18358@ocotillo.lan>
X-SW-Source: 2000-11/msg00215.html
Content-length: 879

On Mon, Nov 20, 2000 at 05:26:13PM -0700, Kevin Buettner wrote:
> On Nov 20,  3:59pm, H . J . Lu wrote:
> 
> > BTW, the EI_OSABI byte is used to tell how to interpret those fields
> > and values which are not defined by gABI nor psABI. It is not to tell
> > on which platform the binary is targeted. [...]
> 
> What is the proper method for determining the target platform?
> 
> (I know how to do it if it's linked against glibc, but not
> otherwise...)
> 

There is no easy way to tell, at least not from the EI_OSABI byte.
That is one reason why glibc did what it did. I was told people thought
about changing EI_OSABI to something else because of the confusion it
might lead to. But they decided against it.

BTW, in the modern world, there should be no static binaries. You can
tell which target a dynamic binary is for by checking PT_INTERP.


-- 
H.J. Lu (hjl@valinux.com)
From Fabrice_Gautier@sdesigns.com Mon Nov 20 18:22:00 2000
From: Fabrice Gautier <Fabrice_Gautier@sdesigns.com>
To: 'Fernando Nasser' <fnasser@cygnus.com>
Cc: "'insight@sources.redhat.com'" <insight@sources.redhat.com>, "GDB (E-mail)" <gdb@sourceware.cygnus.com>
Subject: RE: Buil problem
Date: Mon, 20 Nov 2000 18:22:00 -0000
Message-id: <B1F6452C89AFD411AE0800A0CC734C23015034@EMAIL1>
X-SW-Source: 2000-11/msg00216.html
Content-length: 695

> -----Original Message-----
> From: Fernando Nasser [ mailto:fnasser@cygnus.com ]
> Sent: Monday, November 20, 2000 4:39 PM
> To: Fabrice Gautier
> Cc: 'insight@sources.redhat.com'; GDB (E-mail)
> Subject: Re: Buil problem
> 
> 
> This fix is already in the current sources.  It was broken 
> for a few hours
> and it is very unfortunate you've got it during that window of time.

In fact it came from the latest snapshot... Unfortunate the snapshot was
taken during that window of time...

But i still have a problem, insight won't start in background. If you do 
"i386-elf-gdb &"  the progran stop and i can have it back with "fg". 

Thanks

-- 
Fabrice Gautier
fabrice_gautier@sdesigns.com 
From cgf@redhat.com Mon Nov 20 18:56:00 2000
From: Christopher Faylor <cgf@redhat.com>
To: Fabrice Gautier <Fabrice_Gautier@sdesigns.com>
Cc: "'Fernando Nasser'" <fnasser@cygnus.com>, "'insight@sources.redhat.com'" <insight@sources.redhat.com>, "GDB (E-mail)" <gdb@sources.redhat.com>
Subject: Re: Buil problem
Date: Mon, 20 Nov 2000 18:56:00 -0000
Message-id: <20001120215543.C3169@redhat.com>
References: <B1F6452C89AFD411AE0800A0CC734C23015034@EMAIL1>
X-SW-Source: 2000-11/msg00217.html
Content-length: 644

On Mon, Nov 20, 2000 at 06:21:24PM -0800, Fabrice Gautier wrote:
>> From: Fernando Nasser [ mailto:fnasser@cygnus.com ]
>> 
>> This fix is already in the current sources.  It was broken 
>> for a few hours
>> and it is very unfortunate you've got it during that window of time.
>
>In fact it came from the latest snapshot... Unfortunate the snapshot was
>taken during that window of time...
>
>But i still have a problem, insight won't start in background. If you do 
>"i386-elf-gdb &"  the progran stop and i can have it back with "fg". 

I believe that this has always been a problem with insight.  You can't
start it in the background.

cgf
From Fabrice_Gautier@sdesigns.com Mon Nov 20 19:09:00 2000
From: Fabrice Gautier <Fabrice_Gautier@sdesigns.com>
To: "'insight@sources.redhat.com'" <insight@sources.redhat.com>
Cc: 'Fernando Nasser' <fnasser@cygnus.com>, "GDB (E-mail)" <gdb@sources.redhat.com>
Subject: RE: Buil problem
Date: Mon, 20 Nov 2000 19:09:00 -0000
Message-id: <B1F6452C89AFD411AE0800A0CC734C23015035@EMAIL1>
X-SW-Source: 2000-11/msg00218.html
Content-length: 691

> -----Original Message-----
> From: Christopher Faylor [ mailto:cgf@redhat.com ]
> Subject: Re: Buil problem
> 
> >
> >But i still have a problem, insight won't start in 
> >background. If you do 
> >"i386-elf-gdb &"  the progran stop and i can have it back with "fg". 
> 
> I believe that this has always been a problem with insight.  You can't
> start it in the background.

I believe (no: i'm sure) I did it many times with 5.0 + patches from eCos
website.

I didn't applied the from-the-eCos-website patches to my recent build cause
it seems that they were already applied in the cvs/latest snapshot but maybe
I overlooked something.


-- 
Fabrice Gautier
fabrice_gautier@sdesigns.com 
From fnasser@cygnus.com Mon Nov 20 19:10:00 2000
From: Fernando Nasser <fnasser@cygnus.com>
To: insight@sources.redhat.com
Cc: Fabrice Gautier <Fabrice_Gautier@sdesigns.com>, "GDB (E-mail)" <gdb@sources.redhat.com>
Subject: Re: Buil problem
Date: Mon, 20 Nov 2000 19:10:00 -0000
Message-id: <3A19E781.11269FC1@cygnus.com>
References: <B1F6452C89AFD411AE0800A0CC734C23015034@EMAIL1> <20001120215543.C3169@redhat.com>
X-SW-Source: 2000-11/msg00219.html
Content-length: 872

Christopher Faylor wrote:
> 
> On Mon, Nov 20, 2000 at 06:21:24PM -0800, Fabrice Gautier wrote:
> >> From: Fernando Nasser [ mailto:fnasser@cygnus.com ]
> >>
> >> This fix is already in the current sources.  It was broken
> >> for a few hours
> >> and it is very unfortunate you've got it during that window of time.
> >
> >In fact it came from the latest snapshot... Unfortunate the snapshot was
> >taken during that window of time...
> >
> >But i still have a problem, insight won't start in background. If you do
> >"i386-elf-gdb &"  the progran stop and i can have it back with "fg".
> 
> I believe that this has always been a problem with insight.  You can't
> start it in the background.
> 

Yes, it is a known problem.

-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9
From d_iftikhar@hotmail.com Mon Nov 20 22:23:00 2000
From: "danish iftikhar" <d_iftikhar@hotmail.com>
To: mleibowi@crystal.cirrus.com, fnasser@cygnus.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: Jeeni & ARM720T with GDB
Date: Mon, 20 Nov 2000 22:23:00 -0000
Message-id: <F170WerOc0Ne0PaLI9m00000541@hotmail.com>
X-SW-Source: 2000-11/msg00220.html
Content-length: 1424

>From: Michael Leibowitz <mleibowi@crystal.cirrus.com>
>Reply-To: mleibowi@crystal.cirrus.com
>To: Fernando Nasser <fnasser@cygnus.com>
>CC: danish iftikhar <d_iftikhar@hotmail.com>, gdb@sourceware.cygnus.com
>Subject: Re: Jeeni & ARM720T with GDB
>Date: Mon, 20 Nov 2000 11:04:14 -0600
>
>When I try that, I get an error message:
>
>Continuing.
>RDI_execute: a miscellaneous type of error
>
>Program received signal SIGTERM, Terminated.
>?? () at setup.S:4
>4		B	Reset_Handler
>Current language:  auto; currently asm
>
>using gdb 5.0 (insight w/ -nw) and 7211 eval board.
>
>Any ideas?
>
>On Mon, 20 Nov 2000 10:48:14 Fernando Nasser wrote:
> > The sequence of commands you should use is:
> >
> > file <exec>
> > target rdi e=....
> > load
> > break <somewhere>
> > cont
> >
> >
> > Don't use the load command argument.
>
******************

   Well , i tried to use the above commands and was able to download 
successfully . But after i set break point and do continue , everything 
seems to hang .
Any guesses what is going wrong now .
the rdiromatzero command for EP7211 board should be set at 0 or 1 ??
i am using insight 5.0 .

  do we need to specifically download some program for reset and all those 
things which Grant has told .

regards
danish.


_____________________________________________________________________________________
Get more from the Web.  FREE MSN Explorer download : http://explorer.msn.com