* Re: Jeeni & ARM720T with GDB [not found] <F2693AmsfGdMNFmWAFs00000388@hotmail.com> @ 2000-11-22 6:36 ` Grant Edwards 0 siblings, 0 replies; 5+ messages in thread From: Grant Edwards @ 2000-11-22 6:36 UTC (permalink / raw) To: danish iftikhar; +Cc: fnasser, gdb 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
[parent not found: <F170WerOc0Ne0PaLI9m00000541@hotmail.com>]
* Re: Jeeni & ARM720T with GDB [not found] <F170WerOc0Ne0PaLI9m00000541@hotmail.com> @ 2000-11-21 9:36 ` Fernando Nasser 0 siblings, 0 replies; 5+ messages in thread From: Fernando Nasser @ 2000-11-21 9:36 UTC (permalink / raw) To: danish iftikhar; +Cc: mleibowi, gdb 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
[parent not found: <F262O6hm8Ua8d9Ee4za00002d74@hotmail.com>]
* Re: Jeeni & ARM720T with GDB [not found] <F262O6hm8Ua8d9Ee4za00002d74@hotmail.com> @ 2000-11-20 8:48 ` Fernando Nasser [not found] ` <20001120110414.B23797@spanky> 0 siblings, 1 reply; 5+ messages in thread From: Fernando Nasser @ 2000-11-20 8:48 UTC (permalink / raw) To: danish iftikhar; +Cc: gdb 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. ^ permalink raw reply [flat|nested] 5+ messages in thread
[parent not found: <20001120110414.B23797@spanky>]
* Re: Jeeni & ARM720T with GDB [not found] ` <20001120110414.B23797@spanky> @ 2000-11-20 9:18 ` Fernando Nasser [not found] ` <20001120162925.B11863@visi.com> 1 sibling, 0 replies; 5+ messages in thread From: Fernando Nasser @ 2000-11-20 9:18 UTC (permalink / raw) To: mleibowi; +Cc: danish iftikhar, gdb [-- 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
[parent not found: <20001120162925.B11863@visi.com>]
[parent not found: <20001120173821.B24131@spanky>]
* Re: Jeeni & ARM720T with GDB [not found] ` <20001120173821.B24131@spanky> @ 2000-11-20 15:43 ` Grant Edwards 0 siblings, 0 replies; 5+ messages in thread From: Grant Edwards @ 2000-11-20 15:43 UTC (permalink / raw) To: Michael Leibowitz; +Cc: Fernando Nasser, danish iftikhar, gdb 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2000-11-22 6:36 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <F2693AmsfGdMNFmWAFs00000388@hotmail.com>
2000-11-22 6:36 ` Jeeni & ARM720T with GDB Grant Edwards
[not found] <F170WerOc0Ne0PaLI9m00000541@hotmail.com>
2000-11-21 9:36 ` Fernando Nasser
[not found] <F262O6hm8Ua8d9Ee4za00002d74@hotmail.com>
2000-11-20 8:48 ` Fernando Nasser
[not found] ` <20001120110414.B23797@spanky>
2000-11-20 9:18 ` Fernando Nasser
[not found] ` <20001120162925.B11863@visi.com>
[not found] ` <20001120173821.B24131@spanky>
2000-11-20 15:43 ` Grant Edwards
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox