Re: early buf termination

Re: early buf termination

[Wenbo Yang]

s88 wrote:

>       I'm implementing a gdb stub for my ARM simulator with TCP connection.
> As I query the registers information from gdb, I got
> "fetch_register_using_p: early buf termination" msg.
> 
> (gdb) info registers
> r0             fetch_register_using_p: early buf termination
> (gdb)
> 
> the gdb client send the packet which contains "$p0#a0" to my gdb server.
> The gdb server reply 0 (should be $0#something) to the gdb client.

You can read remote.c:3419 for more information. I think the meaning is:
unexpected message end. It should be more characters but your message
terminated. You should give GDB the standard RSP response.

Regards,
Wenbo
-- 
Wenbo Yang

The State Key Lab. of Information Security
Graduate School of CAS, 19A Yuquan Road, Beijing, China
Homepage: http://solrex.cn

SimpLight Nanoelectronics Ltd. 6 Zhichun Road, 10th Floor, Beijing, China
Phone: +86-10-5126-6989   ---  Email: wenbo.yang@simplnano.com

Re: RSP handling

[Wenbo Yang]

> s88 wrote:
> 
 > but something is strange after the connection created. I set a
 > breakpoint in the main function (br main), but after the connection
 > created the gdb stop at the first instruction of crt0.S.
Is there anything wrong? Your stub gave GDB where the PC pointed to, and GDB 
printed it out with source code accordingly. You didn't start debugging, you 
were just attaching to the target. The PC you got should be the saved PC value 
while enter exception handler(stub). It has little meaning, you can go ahead by 
"continue".

Wenbo
-- 
Wenbo Yang

The State Key Lab. of Information Security
Graduate School of CAS, 19A Yuquan Road, Beijing, China
Homepage: http://solrex.cn

SimpLight Nanoelectronics Ltd. 6 Zhichun Road, 10th Floor, Beijing, China
Phone: +86-10-5126-6989   ---  Email: wenbo.yang@simplnano.com

Re: RSP handling

[Jim Blandy]

Wenbo Yang <wenbo.yang@simplnano.com> writes:
>> but something is strange after the connection created. I set a
>> breakpoint in the main function (br main), but after the connection
>> created the gdb stop at the first instruction of crt0.S.
> Is there anything wrong? Your stub gave GDB where the PC pointed to,
> and GDB printed it out with source code accordingly. You didn't start
> debugging, you were just attaching to the target. The PC you got
> should be the saved PC value while enter exception handler(stub). It
> has little meaning, you can go ahead by "continue".

Right.  When you connect to a target via the remote protocol, GDB
treats that as connecting to a program that's already running; it's
showing you the location where it's currently stopped.

RSP handling

[s88]

Hi all:
My gdb is configured as "--host=i686-pc-linux-gnu --target=arm-elf"
and remote debugging with an arm simulator which be a target.

but something is strange after the connection created. I set a
breakpoint in the main function (br main), but after the connection
created the gdb stop at the first instruction of crt0.S.
(gdb) target remote 140.123.103.7:23137
Remote debugging using 140.123.103.7:23137
start () at ../../../../../../gcc-3.4.1/newlib/libc/sys/arm/crt0.S:36
36              mov     r0, #AngelSWI_Reason_HeapInfo
Current language:  auto; currently asm
(gdb)

Maybe my gdb stub doesn't handle the packet well.
Following is the command form gdb and the correspond reply by my gdb stub.

waiting for GDB connection establish...
A new GDB connection established
received from gdb ... $qSupported#37 <--from gdb
reply=''                                             <--gdb stub reply to gdb
received from gdb ... +
received from gdb ... $Hc-1#09
reply='OK'
received from gdb ... $qC#b4
reply='*'
received from gdb ... $qOffsets#4b
reply='Text=0;Data=0;Bss=0'
received from gdb ... $qOffsets#4b
reply='Text=0;Data=0;Bss=0'
received from gdb ... $?#3f
reply='S05'
received from gdb ... $Hg0#df
reply='OK'
received from gdb ... $pf#d6
reply='10810000'
received from gdb ... $m8110,4#97
reply='1600a0e3'
received from gdb ... $qSymbol::#5b
reply='OK'

any suggestion?

best regards,

Dave.

-- 
System  on Chip Design  Lab.
Dept. of Computer Science and Information Engineering,
National Chung Cheng University
E-mail : s88.tw@acm.org