* target_op(..) -> target_op(target, ...) obvious @ 2003-10-09 13:13 Andrew Cagney 2003-10-09 13:55 ` Andrew Cagney 2003-10-09 19:39 ` Jim Blandy 0 siblings, 2 replies; 8+ messages in thread From: Andrew Cagney @ 2003-10-09 13:13 UTC (permalink / raw) To: gdb As part of the on-going OO of GDB, the "target vector" is one of the next things up for treatment. I'd like to be sure that everyones ok with the mechanical transformatioin: target_OP (...) -> taget_OP (target, ...) being considered "fairly obvious" (post patch, give it a few days, commit patch). Pushing the target around is going to involve touching files across maintenance boundraries. thoughts? Andrew ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: target_op(..) -> target_op(target, ...) obvious 2003-10-09 13:13 target_op(..) -> target_op(target, ...) obvious Andrew Cagney @ 2003-10-09 13:55 ` Andrew Cagney 2003-10-09 19:39 ` Jim Blandy 1 sibling, 0 replies; 8+ messages in thread From: Andrew Cagney @ 2003-10-09 13:55 UTC (permalink / raw) To: Andrew Cagney; +Cc: gdb > As part of the on-going OO of GDB, the "target vector" is one of the next things up for treatment. I'd like to be sure that everyones ok with the mechanical transformatioin: > > target_OP (...) -> taget_OP (target, ...) > > being considered "fairly obvious" (post patch, give it a few days, commit patch). Pushing the target around is going to involve touching files across maintenance boundraries. [Not my day.] The rationale is the same as for the architecture vector along with the push to eliminate global thread/frame state. It is to make it possible to have multiple instances of a specific target. For instance,two ptrace inferior's, or two active remotes. Andrew ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: target_op(..) -> target_op(target, ...) obvious 2003-10-09 13:13 target_op(..) -> target_op(target, ...) obvious Andrew Cagney 2003-10-09 13:55 ` Andrew Cagney @ 2003-10-09 19:39 ` Jim Blandy 2003-10-09 20:36 ` Andrew Cagney 1 sibling, 1 reply; 8+ messages in thread From: Jim Blandy @ 2003-10-09 19:39 UTC (permalink / raw) To: Andrew Cagney; +Cc: gdb Andrew Cagney <ac131313@redhat.com> writes: > As part of the on-going OO of GDB, the "target vector" is one of the > next things up for treatment. I'd like to be sure that everyones ok > with the mechanical transformatioin: > > target_OP (...) -> taget_OP (target, ...) > > being considered "fairly obvious" (post patch, give it a few days, > commit patch). Pushing the target around is going to involve touching > files across maintenance boundraries. So, in this patch, the calls would all pass a pointer to the global variable 'current_target', right? Or would it also include changes to functions' interfaces to pass the target around explicitly? ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: target_op(..) -> target_op(target, ...) obvious 2003-10-09 19:39 ` Jim Blandy @ 2003-10-09 20:36 ` Andrew Cagney 2003-10-10 2:06 ` remote serial protocol - gdbserver saleru.raja 0 siblings, 1 reply; 8+ messages in thread From: Andrew Cagney @ 2003-10-09 20:36 UTC (permalink / raw) To: Jim Blandy; +Cc: gdb > Andrew Cagney <ac131313@redhat.com> writes: > >> As part of the on-going OO of GDB, the "target vector" is one of the >> next things up for treatment. I'd like to be sure that everyones ok >> with the mechanical transformatioin: >> >> target_OP (...) -> taget_OP (target, ...) >> >> being considered "fairly obvious" (post patch, give it a few days, >> commit patch). Pushing the target around is going to involve touching >> files across maintenance boundraries. > > > So, in this patch, the calls would all pass a pointer to the global > variable 'current_target', right? Or would it also include changes to > functions' interfaces to pass the target around explicitly? "yes". Just like regcache, gdbarch, and frame, it would start out using current_gdbarch but then, over time evolve, to more correctly pass explicit parameters (be that frame, thread, regcache, or target). Oh, "this patch" doesn't exist. The intent is for this, again just like the other changes, to be rolled out over comming months. Oh, one motivation for me starting process is that it will let me parameterize CONVERT_FROM_FUNC_PTR_ADDR with an explicit target and that will in turn let me fix the entry-point problem you encountered with PPC64 GNU/Linux. Andrew ^ permalink raw reply [flat|nested] 8+ messages in thread
* remote serial protocol - gdbserver 2003-10-09 20:36 ` Andrew Cagney @ 2003-10-10 2:06 ` saleru.raja 2003-10-10 2:28 ` Andrew Cagney 0 siblings, 1 reply; 8+ messages in thread From: saleru.raja @ 2003-10-10 2:06 UTC (permalink / raw) To: gdb Hi, I have a querry related to remote serial protocl. I have been ported gdbserver on RTOS (micro itron) running on SH3 processor. while debugging the remote application with "next" user command from gdb, Gdb send the following packets to gdbserver m0,2#fb M0,2:20c3#0d simmilary for Z packet with zero address. Here if the address is zero, what does it mean ? for example in this packet "M0,2:20c3#0d" where the TRAP instruction should be write ? where the data should be read from or write into ? The solution for this querry will be greatly appreciated. - Regards Raja s ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: remote serial protocol - gdbserver 2003-10-10 2:06 ` remote serial protocol - gdbserver saleru.raja @ 2003-10-10 2:28 ` Andrew Cagney 2003-10-10 5:15 ` Raja Saleru 0 siblings, 1 reply; 8+ messages in thread From: Andrew Cagney @ 2003-10-10 2:28 UTC (permalink / raw) To: saleru.raja; +Cc: gdb > Hi, > I have a querry related to remote serial protocl. > > I have been ported gdbserver on RTOS (micro itron) running on SH3 > processor. > while debugging the remote application with "next" user command from gdb, > > Gdb send the following packets to gdbserver > > m0,2#fb > M0,2:20c3#0d > > simmilary for Z packet with zero address. > > Here if the address is zero, what does it mean ? for example in this > packet "M0,2:20c3#0d" where the TRAP instruction should be write ? > where the data should be read from or write into ? > > The solution for this querry will be greatly appreciated. Can you post a gdb session with "set debug remote 1" enabled? A wild guess is that it's trying to set a breakpoint at the return address of the function it's trying to NEXT over, only its getting that return address wrong. Andrew ^ permalink raw reply [flat|nested] 8+ messages in thread
* RE: remote serial protocol - gdbserver 2003-10-10 2:28 ` Andrew Cagney @ 2003-10-10 5:15 ` Raja Saleru 2003-10-11 15:40 ` Andrew Cagney 0 siblings, 1 reply; 8+ messages in thread From: Raja Saleru @ 2003-10-10 5:15 UTC (permalink / raw) To: 'Andrew Cagney', saleru.raja; +Cc: gdb Hi, please find the session. ------------------------------------------------------------------------ ------------------------------------------- [root@prism gdbserver_test]# sh-elf-gdb GdbServer_Test GNU gdb 6.0 Copyright 2003 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "--host=i686-pc-linux-gnu --target=sh-elf"... Sending packet: $Hc-1#09...Ack Packet received: OK Sending packet: $qC#b4...Ack Packet received: QC2 Sending packet: $qOffsets#4b...Ack Packet received: Text=8c5e8354;Data=8c5e9368;Bss=8c5ea37c Sending packet: $?#3f...Ack Packet received: T0510:54835e8c;0e:00000000;0f:7466658c; Sending packet: $m0,4#fd...Ack Packet received: 8867658c __entry (param=0x8c656788) at crt0.c:26 26 { (gdb) b main Breakpoint 1 at 0x8c5e83d4: file GdbServer_Test.c, line 38. (gdb) c Continuing. Sending packet: $Z0,8c5e83d4,2#4c...Ack Packet received: Packet Z0 (software-breakpoint) is NOT supported Sending packet: $m8c5e83d4,2#03...Ack Packet received: 04d1 Sending packet: $X8c5e83d4,0:#26...Ack Packet received: binary downloading NOT suppported by target Sending packet: $M8c5e83d4,2:20c3#15...Ack Packet received: OK Sending packet: $Hc0#db...Ack Packet received: OK Sending packet: $c#63...Ack Packet received: T0510:d4835e8c;0e:9866658c;0f:ac835e8c; Sending packet: $m8c5e83c8,2#06...Ack Packet received: e62f Sending packet: $m8c5e83ca,2#2f...Ack Packet received: 224f Sending packet: $m8c5e83cc,2#31...Ack Packet received: f87f Sending packet: $m8c5e83ce,2#33...Ack Packet received: f36e Sending packet: $m8c6566a4,4#d4...Ack Packet received: b066658c Sending packet: $m8c5e83c8,2#06...Ack Packet received: e62f Sending packet: $m8c5e83ca,2#2f...Ack Packet received: 224f Sending packet: $m8c5e83cc,2#31...Ack Packet received: f87f Sending packet: $m8c5e83ce,2#33...Ack Packet received: f36e Sending packet: $m8c6566a4,4#d4...Ack Packet received: b066658c Sending packet: $m8c6566a0,4#d0...Ack Packet received: ac835e8c Sending packet: $M8c5e83d4,2:04d1#16...Ack Packet received: OK Sending packet: $m8c656698,4#b0...Ack Packet received: 02000000 Sending packet: $m8c65669c,4#db...Ack Packet received: a866658c Breakpoint 1, main (argc=2, argv=0x8c6566a8) at GdbServer_Test.c:38 38 Application(); (gdb) l 33 34 extern void Application(); 35 36 int main(int argc, char **argv) 37 { 38 Application(); 39 40 return 0; 41 } 42 (gdb) s Sending packet: $Hc2#dd...Ack Packet received: OK Sending packet: $s#73...Ack Packet received: T0510:d6835e8c;0e:9866658c;0f:ac835e8c; Sending packet: $m8c5e83d4,2#03...Ack Packet received: 04d1 Sending packet: $M8c5e83d4,2:20c3#15...Ack Packet received: OK Sending packet: $Hc0#db...Ack Packet received: OK Sending packet: $s#73...Ack Packet received: T0510:10845e8c;0e:9866658c;0f:da835e8c; Sending packet: $m8c5e841c,2#00...Ack Packet received: 67d1 Sending packet: $M8c5e841c,2:20c3#12...Ack Packet received: OK Sending packet: $c#63...Ack Packet received: T0510:1c845e8c;0e:1466658c;0f:da835e8c; Sending packet: $M8c5e841c,2:67d1#1c...Ack Packet received: OK Sending packet: $m8c5e8410,2#cd...Ack Packet received: 862f Sending packet: $m8c5e8412,2#cf...Ack Packet received: 962f Sending packet: $m8c5e8414,2#d1...Ack Packet received: e62f Sending packet: $m8c5e8416,2#d3...Ack Packet received: 224f Sending packet: $m8c5e8418,2#d5...Ack Packet received: 8c7f Sending packet: $m8c5e841a,2#fe...Ack Packet received: f36e Sending packet: $m8c65668c,4#da...Ack Packet received: 9866658c Sending packet: $m8c5e8410,2#cd...Ack Packet received: 862f Sending packet: $m8c5e8412,2#cf...Ack Packet received: 962f Sending packet: $m8c5e8414,2#d1...Ack Packet received: e62f Sending packet: $m8c5e8416,2#d3...Ack Packet received: 224f Sending packet: $m8c5e8418,2#d5...Ack Packet received: 8c7f Sending packet: $m8c5e841a,2#fe...Ack Packet received: f36e Sending packet: $m8c65668c,4#da...Ack Packet received: 9866658c Sending packet: $m8c656688,4#af...Ack Packet received: da835e8c Sending packet: $M8c5e83d4,2:04d1#16...Ack Packet received: OK Application () at application.c:58 58 mmUserPrint(" Enter Root task\n"); (gdb) l 53 T_RFLG pk_rflg; 54 T_RVER pk_rver; 55 56 INT err; 57 58 mmUserPrint(" Enter Root task\n"); 59 60 /* o[WQ?*/ 61 err = tk_ref_ver( &pk_rver ); 62 if( err != E_OK) (gdb) n Sending packet: $m8c5e83d4,2#03...Ack Packet received: 04d1 Sending packet: $M8c5e83d4,2:20c3#15...Ack Packet received: OK Sending packet: $s#73...Ack Packet received: T0510:1e845e8c;0e:1466658c;0f:da835e8c; Sending packet: $s#73...Ack Packet received: T0510:20845e8c;0e:1466658c;0f:da835e8c; Sending packet: $s#73...Ack Packet received: T0510:22845e8c;0e:1466658c;0f:da835e8c; Sending packet: $s#73...Ack Packet received: T0510:2874008c;0e:1466658c;0f:26845e8c; Sending packet: $Hg2#e1...Ack Packet received: OK Sending packet: $g#67...Ack Packet received: 000000002874008ca866658c00000000b0935e8ca866658c000000000000000000000000 00000000000000000000000000000000000000001466658c26845e8c2874008c00000000 0000008c0000000000000000000000000000006008000000000000000000000004000000 000000002e000000040000000000000000000000487d0000180000001600000004000000 040000000c00000039000000080000000300000000000000c81200000000000000000000 0000000004000000000000003e000000010000000000000000000000c812000030000000 000000000000000001000000000000004c000000 Sending packet: $m0,2#fb...Ack ------------------------------------- <1> Packet received: b0935e8c Sending packet: $M0,2:20c3#0d...Ack ------------------------------------- <2> Packet received: OK Sending packet: $c#63...Ack Packet received: T0510:2874008c;0e:1466658c;0f:26845e8c; Program received signal SIGTRAP, Trace/breakpoint trap. Sending packet: $M0,2:b093#13...Ack ------------------------------------- <3> Packet received: OK Sending packet: $M8c5e83d4,2:04d1#16...Ack Packet received: OK 0x8c007428 in ?? () (gdb) ------------------------------------------------------------------------ -------------------------------------------------------------- here after the next command you can find the memory read and write operation with zero address. I would like to know more on this. - Raja S -----Original Message----- From: gdb-owner@sources.redhat.com [mailto:gdb-owner@sources.redhat.com] On Behalf Of Andrew Cagney Sent: Friday, October 10, 2003 11:28 AM To: saleru.raja@iap-online.com Cc: gdb@sources.redhat.com Subject: Re: remote serial protocol - gdbserver > Hi, > I have a querry related to remote serial protocl. > > I have been ported gdbserver on RTOS (micro itron) running on SH3 > processor. while debugging the remote application with "next" user > command from gdb, > > Gdb send the following packets to gdbserver > > m0,2#fb > M0,2:20c3#0d > > simmilary for Z packet with zero address. > > Here if the address is zero, what does it mean ? for example in this > packet "M0,2:20c3#0d" where the TRAP instruction should be write ? > where the data should be read from or write into ? > > The solution for this querry will be greatly appreciated. Can you post a gdb session with "set debug remote 1" enabled? A wild guess is that it's trying to set a breakpoint at the return address of the function it's trying to NEXT over, only its getting that return address wrong. Andrew ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: remote serial protocol - gdbserver 2003-10-10 5:15 ` Raja Saleru @ 2003-10-11 15:40 ` Andrew Cagney 0 siblings, 0 replies; 8+ messages in thread From: Andrew Cagney @ 2003-10-11 15:40 UTC (permalink / raw) To: Raja Saleru; +Cc: saleru.raja, gdb My wild guess appears to be correct ... > (gdb) l > 53 T_RFLG pk_rflg; > 54 T_RVER pk_rver; > 55 > 56 INT err; > 57 > 58 mmUserPrint(" Enter Root task\n"); > 59 > 60 /* o[WQ?*/ > 61 err = tk_ref_ver( &pk_rver ); > 62 if( err != E_OK) > (gdb) n > Sending packet: $m8c5e83d4,2#03...Ack > Packet received: 04d1 > Sending packet: $M8c5e83d4,2:20c3#15...Ack > Packet received: OK > Sending packet: $s#73...Ack > Packet received: T0510:1e845e8c;0e:1466658c;0f:da835e8c; > Sending packet: $s#73...Ack > Packet received: T0510:20845e8c;0e:1466658c;0f:da835e8c; > Sending packet: $s#73...Ack > Packet received: T0510:22845e8c;0e:1466658c;0f:da835e8c; > Sending packet: $s#73...Ack > Packet received: T0510:2874008c;0e:1466658c;0f:26845e8c; I'm guessing that 2874008c is the PC in little-endian byte order. It's just stepped the target into mmUserPrint. > Sending packet: $Hg2#e1...Ack > Packet received: OK > Sending packet: $g#67...Ack > Packet received: > 000000002874008ca866658c00000000b0935e8ca866658c000000000000000000000000 > 00000000000000000000000000000000000000001466658c26845e8c2874008c00000000 > 0000008c0000000000000000000000000000006008000000000000000000000004000000 > 000000002e000000040000000000000000000000487d0000180000001600000004000000 > 040000000c00000039000000080000000300000000000000c81200000000000000000000 > 0000000004000000000000003e000000010000000000000000000000c812000030000000 > 000000000000000001000000000000004c000000 It's pulled the target's registers looking for the "link-register" which should contain the return address. > Sending packet: $m0,2#fb...Ack > ------------------------------------- <1> > Packet received: b0935e8c > Sending packet: $M0,2:20c3#0d...Ack and then sets a breakpoint at that return-address. For some reason GDB think's that's zero (bad packet? bad gdb?). BTW: "b0935e8c" is a bogus return value for "$m0,2,#fb", only two bytes were requested but four were returned, which is wrong (at present). Andrew > ------------------------------------- <2> > Packet received: OK > Sending packet: $c#63...Ack > Packet received: T0510:2874008c;0e:1466658c;0f:26845e8c; > > Program received signal SIGTRAP, Trace/breakpoint trap. ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2003-10-11 15:40 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-10-09 13:13 target_op(..) -> target_op(target, ...) obvious Andrew Cagney 2003-10-09 13:55 ` Andrew Cagney 2003-10-09 19:39 ` Jim Blandy 2003-10-09 20:36 ` Andrew Cagney 2003-10-10 2:06 ` remote serial protocol - gdbserver saleru.raja 2003-10-10 2:28 ` Andrew Cagney 2003-10-10 5:15 ` Raja Saleru 2003-10-11 15:40 ` Andrew Cagney
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).