target_op(..) -> target_op(target, ...) obvious

target_op(..) -> target_op(target, ...) obvious

[Andrew Cagney]

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

Re: target_op(..) -> target_op(target, ...) obvious

[Andrew Cagney]

> 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

Re: target_op(..) -> target_op(target, ...) obvious

[Jim Blandy]

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?

Re: target_op(..) -> target_op(target, ...) obvious

[Andrew Cagney]

> 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

remote serial protocol - gdbserver

[saleru.raja]

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

Re: remote serial protocol - gdbserver

[Andrew Cagney]

> 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

RE: remote serial protocol - gdbserver

[Raja Saleru]

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

Re: remote serial protocol - gdbserver

[Andrew Cagney]

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.