Mirror of the gdb mailing list
 help / color / mirror / Atom feed
* GDB Remote debug: Why several "$Z0,address,length" msg when only set one breakpoint?
@ 2014-08-26  6:57 Peng Fan
  2014-08-26 13:18 ` Luis Machado
  2014-08-27  0:36 ` Yao Qi
  0 siblings, 2 replies; 7+ messages in thread
From: Peng Fan @ 2014-08-26  6:57 UTC (permalink / raw)
  To: gdb

Hi,

Currently, I am hacking uboot arm kgdb and adding breakpoint support.

The steps is as following:
(gdb) b do_bootz
Breakpoint 1, do_bootz (cmdtp=0x8784ca14 <_u_boot_list_2_cmd_2_bootz>, flag=0, argc=1, argv=0xbf552a20) at common/cmd_bootm.c:1928
(gdb) c
Continuing.
Sending packet: $m87809580,4#7a...Ack
Packet received: f0452de9
Sending packet: $m87809580,4#7a...Ack
Packet received: f0452de9
Sending packet: $Z0,87809584,4#c7...Ack
Packet received: OK
Sending packet: $Hc0#db...Ack
Packet received: 
Sending packet: $c#63...Ack
Packet received: T050f:84958087;0d:a41355bf;
Sending packet: $z0,87809584,4#e7...Ack
Packet received: OK
Sending packet: $qTStatus#49...Ack
Packet received: 
Sending packet: $Z0,87800000,4#ad...Ack
Packet received: OK
Sending packet: $Z0,87809580,4#c3...Ack
Packet received: OK
Sending packet: $Hc0#db...Ack
Packet received: 
Sending packet: $c#63...Ack

Actually the breakpoint is at 0x87809580, but why first set breakpoint at 0x87809584 then remove it then set breakpoint at 0x87809580?

Also the first time set a breakpoint then continue.
(gdb) c
Continuing.
Sending packet: $qTStatus#49...Ack
Packet received: 
Sending packet: $Z0,87800000,4#ad...Ack
Packet received: OK
Packet Z0 (software-breakpoint) is supported
Sending packet: $Z0,87809580,4#c3...Ack
Packet received: OK
Sending packet: $vCont?#49...Ack
Packet received: 
Packet vCont (verbose-resume) is NOT supported
Sending packet: $Hc0#db...Ack
Packet received: 
Sending packet: $c#63...Ack

why two Z0 here? I only set break at 0x87809580, but gdb send a break set at 0x87800000 which is the beginning of the elf entry.

Thanks.
Peng.


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: GDB Remote debug: Why several "$Z0,address,length" msg when only set one breakpoint?
  2014-08-26  6:57 GDB Remote debug: Why several "$Z0,address,length" msg when only set one breakpoint? Peng Fan
@ 2014-08-26 13:18 ` Luis Machado
  2014-08-27  0:36 ` Yao Qi
  1 sibling, 0 replies; 7+ messages in thread
From: Luis Machado @ 2014-08-26 13:18 UTC (permalink / raw)
  To: Peng Fan, gdb

On 08/26/2014 03:57 AM, Peng Fan wrote:
> Hi,
>
> Currently, I am hacking uboot arm kgdb and adding breakpoint support.
>
> The steps is as following:
> (gdb) b do_bootz
> Breakpoint 1, do_bootz (cmdtp=0x8784ca14 <_u_boot_list_2_cmd_2_bootz>, flag=0, argc=1, argv=0xbf552a20) at common/cmd_bootm.c:1928
> (gdb) c
> Continuing.
> Sending packet: $m87809580,4#7a...Ack
> Packet received: f0452de9
> Sending packet: $m87809580,4#7a...Ack
> Packet received: f0452de9
> Sending packet: $Z0,87809584,4#c7...Ack
> Packet received: OK
> Sending packet: $Hc0#db...Ack
> Packet received:
> Sending packet: $c#63...Ack
> Packet received: T050f:84958087;0d:a41355bf;
> Sending packet: $z0,87809584,4#e7...Ack
> Packet received: OK
> Sending packet: $qTStatus#49...Ack
> Packet received:
> Sending packet: $Z0,87800000,4#ad...Ack
> Packet received: OK
> Sending packet: $Z0,87809580,4#c3...Ack
> Packet received: OK
> Sending packet: $Hc0#db...Ack
> Packet received:
> Sending packet: $c#63...Ack
>
> Actually the breakpoint is at 0x87809580, but why first set breakpoint at 0x87809584 then remove it then set breakpoint at 0x87809580?
>
> Also the first time set a breakpoint then continue.
> (gdb) c
> Continuing.
> Sending packet: $qTStatus#49...Ack
> Packet received:
> Sending packet: $Z0,87800000,4#ad...Ack
> Packet received: OK
> Packet Z0 (software-breakpoint) is supported
> Sending packet: $Z0,87809580,4#c3...Ack
> Packet received: OK
> Sending packet: $vCont?#49...Ack
> Packet received:
> Packet vCont (verbose-resume) is NOT supported
> Sending packet: $Hc0#db...Ack
> Packet received:
> Sending packet: $c#63...Ack
>
> why two Z0 here? I only set break at 0x87809580, but gdb send a break set at 0x87800000 which is the beginning of the elf entry.
>
> Thanks.
> Peng.
>
>

ARM does not have hardware single-stepping support, so GDB needs to 
simulate it with continue requests and breakpoints.

Regarding additional breakpoints, GDB has its own internal breakpoints, 
so your session may not be restricted to the breakpoints you created.

On third reason, depending on the mode, GDB inserts and removes 
breakpoints with every program stop.


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: GDB Remote debug: Why several "$Z0,address,length" msg when only set one breakpoint?
  2014-08-26  6:57 GDB Remote debug: Why several "$Z0,address,length" msg when only set one breakpoint? Peng Fan
  2014-08-26 13:18 ` Luis Machado
@ 2014-08-27  0:36 ` Yao Qi
  2014-08-27  7:50   ` Peng Fan
  1 sibling, 1 reply; 7+ messages in thread
From: Yao Qi @ 2014-08-27  0:36 UTC (permalink / raw)
  To: Peng Fan; +Cc: gdb

Peng Fan <van.freenix@gmail.com> writes:

It is a typical step-over-breakpoint process in GDB,

> Sending packet: $m87809580,4#7a...Ack
> Packet received: f0452de9
> Sending packet: $m87809580,4#7a...Ack
> Packet received: f0452de9

Looks like the program hits the breakpoint on 0x87809580, and 'c'
command is being executed.  Before GDB resume the inferior, it will
execute the instruction in a single-step fashion on the address
where the breakpoint is set, because it isn't executed yet.

GDB read the instruction on address 0x87809580, decode it and know what
is the address of next instruction,

> Sending packet: $Z0,87809584,4#c7...Ack
> Packet received: OK

and insert the breakpoint on next instruction for software single step,

> Sending packet: $Hc0#db...Ack
> Packet received: 
> Sending packet: $c#63...Ack
> Packet received: T050f:84958087;0d:a41355bf;
> Sending packet: $z0,87809584,4#e7...Ack
> Packet received: OK
> Sending packet: $qTStatus#49...Ack

resume the program, and it hits the breakpoint on 0x87809584.  Then,
instruction on 0x8780950 is executed.

> Packet received: 
> Sending packet: $Z0,87800000,4#ad...Ack
> Packet received: OK
> Sending packet: $Z0,87809580,4#c3...Ack
> Packet received: OK

Restore the breakpoint on 0x87809580.

> Sending packet: $Hc0#db...Ack
> Packet received: 
> Sending packet: $c#63...Ack

Resume the inferior and keep waiting.

>
> Actually the breakpoint is at 0x87809580, but why first set breakpoint
> at 0x87809584 then remove it then set breakpoint at 0x87809580?
>

My comments above answer your question.

> Also the first time set a breakpoint then continue.
> (gdb) c
> Continuing.
> Sending packet: $qTStatus#49...Ack
> Packet received: 
> Sending packet: $Z0,87800000,4#ad...Ack
> Packet received: OK
> Packet Z0 (software-breakpoint) is supported
> Sending packet: $Z0,87809580,4#c3...Ack
> Packet received: OK
> Sending packet: $vCont?#49...Ack
> Packet received: 
> Packet vCont (verbose-resume) is NOT supported
> Sending packet: $Hc0#db...Ack
> Packet received: 
> Sending packet: $c#63...Ack
>
> why two Z0 here? I only set break at 0x87809580, but gdb send a break
> set at 0x87800000 which is the beginning of the elf entry.

What is the symbol on 0x87800000? GDB inserts some internal breakpoints
for some purpose, collecting interesting events, for example.

-- 
Yao (齐尧)


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: GDB Remote debug: Why several "$Z0,address,length" msg when only set one breakpoint?
  2014-08-27  0:36 ` Yao Qi
@ 2014-08-27  7:50   ` Peng Fan
  2014-08-27 12:15     ` Yao Qi
  0 siblings, 1 reply; 7+ messages in thread
From: Peng Fan @ 2014-08-27  7:50 UTC (permalink / raw)
  To: Yao Qi; +Cc: gdb



On 08/27/2014 08:32 AM, Yao Qi wrote:
> Peng Fan <van.freenix@gmail.com> writes:
> 
> It is a typical step-over-breakpoint process in GDB,
> 
>> Sending packet: $m87809580,4#7a...Ack
>> Packet received: f0452de9
>> Sending packet: $m87809580,4#7a...Ack
>> Packet received: f0452de9
> 
> Looks like the program hits the breakpoint on 0x87809580, and 'c'
> command is being executed.  Before GDB resume the inferior, it will
> execute the instruction in a single-step fashion on the address
> where the breakpoint is set, because it isn't executed yet.
Yeah. the program hits the breakpoint at 0x87809580. then 'c'.
> 
> GDB read the instruction on address 0x87809580, decode it and know what
> is the address of next instruction,
> 
>> Sending packet: $Z0,87809584,4#c7...Ack
>> Packet received: OK
> 
> and insert the breakpoint on next instruction for software single step,
> 
>> Sending packet: $Hc0#db...Ack
>> Packet received: 
>> Sending packet: $c#63...Ack
>> Packet received: T050f:84958087;0d:a41355bf;
>> Sending packet: $z0,87809584,4#e7...Ack
>> Packet received: OK
>> Sending packet: $qTStatus#49...Ack
> 
> resume the program, and it hits the breakpoint on 0x87809584.  Then,
> instruction on 0x8780950 is executed.
> 
>> Packet received: 
>> Sending packet: $Z0,87800000,4#ad...Ack
>> Packet received: OK
>> Sending packet: $Z0,87809580,4#c3...Ack
>> Packet received: OK
> 
> Restore the breakpoint on 0x87809580.
> 
>> Sending packet: $Hc0#db...Ack
>> Packet received: 
>> Sending packet: $c#63...Ack
> 
> Resume the inferior and keep waiting.
Yeah. Detailed. Got it. Thanks.
> 
>>
>> Actually the breakpoint is at 0x87809580, but why first set breakpoint
>> at 0x87809584 then remove it then set breakpoint at 0x87809580?
>>
> 
> My comments above answer your question.
> 
>> Also the first time set a breakpoint then continue.
>> (gdb) c
>> Continuing.
>> Sending packet: $qTStatus#49...Ack
>> Packet received: 
>> Sending packet: $Z0,87800000,4#ad...Ack
>> Packet received: OK
>> Packet Z0 (software-breakpoint) is supported
>> Sending packet: $Z0,87809580,4#c3...Ack
>> Packet received: OK
>> Sending packet: $vCont?#49...Ack
>> Packet received: 
>> Packet vCont (verbose-resume) is NOT supported
>> Sending packet: $Hc0#db...Ack
>> Packet received: 
>> Sending packet: $c#63...Ack
>>
>> why two Z0 here? I only set break at 0x87809580, but gdb send a break
>> set at 0x87800000 which is the beginning of the elf entry.
> 
> What is the symbol on 0x87800000? GDB inserts some internal breakpoints
> for some purpose, collecting interesting events, for example.
> 
Actually, there is a pair of "$z0,87800000,4" and "$Z0,87800000,4" of each 'c' except the first time to executing 'c'.
The first time 'c', there is only "$Z0,87800000,4" to set a breakpoint. 
0x87800000 is the entry symbol address of u-boot elf of my platform.
    1                                                                                 
    2 u-boot:     file format elf32-littlearm                                         
    3                                                                                 
    4                                                                                 
    5 Disassembly of section .text:                                                   
    6                                                                                 
    7 87800000 <__image_copy_start>:                                                  
    8 87800000: 11 00 00 ea 14 f0 9f e5 14 f0 9f e5 14 f0 9f e5
    9 87800010: 14 f0 9f e5 14 f0 9f e5 14 f0 9f e5 14 f0 9f e5 

Regards,
Peng.


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: GDB Remote debug: Why several "$Z0,address,length" msg when only set one breakpoint?
  2014-08-27  7:50   ` Peng Fan
@ 2014-08-27 12:15     ` Yao Qi
  2014-08-27 21:58       ` Pedro Alves
  0 siblings, 1 reply; 7+ messages in thread
From: Yao Qi @ 2014-08-27 12:15 UTC (permalink / raw)
  To: Peng Fan; +Cc: gdb

Peng Fan <van.freenix@gmail.com> writes:

> 0x87800000 is the entry symbol address of u-boot elf of my platform.
>     1                                                                                 
>     2 u-boot:     file format elf32-littlearm                                         
>     3                                                                                 
>     4                                                                                 
>     5 Disassembly of section .text:                                                   
>     6                                                                                 
>     7 87800000 <__image_copy_start>:                                                  
>     8 87800000: 11 00 00 ea 14 f0 9f e5 14 f0 9f e5 14 f0 9f e5
>     9 87800010: 14 f0 9f e5 14 f0 9f e5 14 f0 9f e5 14 f0 9f e5 

GDB is interested in entry address, but I don't know why GDB insert
breakpoint there.  In GDB, command 'maintenance info breakpoints' can
list all the user breakpoints and internal breakpoints.  If it still
doesn't help, you can debug your gdb, set breakpoint
remote_insert_breakpoint, and check why the breakpoint is inserted at
0x87800000.

-- 
Yao (齐尧)


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: GDB Remote debug: Why several "$Z0,address,length" msg when only set one breakpoint?
  2014-08-27 12:15     ` Yao Qi
@ 2014-08-27 21:58       ` Pedro Alves
  2014-08-28  1:21         ` Peng Fan
  0 siblings, 1 reply; 7+ messages in thread
From: Pedro Alves @ 2014-08-27 21:58 UTC (permalink / raw)
  To: Yao Qi, Peng Fan; +Cc: gdb

On 08/27/2014 01:11 PM, Yao Qi wrote:

> GDB is interested in entry address, but I don't know why GDB insert
> breakpoint there.  In GDB, command 'maintenance info breakpoints' can
> list all the user breakpoints and internal breakpoints.  If it still
> doesn't help, you can debug your gdb, set breakpoint
> remote_insert_breakpoint, and check why the breakpoint is inserted at
> 0x87800000.

I'd guess this is a build of GDB targeting Linux, and then that
breakpoint is the solib-event breakpoint.  One of the
last-resort addresses solib-svr4.c tries is _start:

static const char * const bkpt_names[] =
{
  "_start",
...

Thanks,
Pedro Alves


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: GDB Remote debug: Why several "$Z0,address,length" msg when only set one breakpoint?
  2014-08-27 21:58       ` Pedro Alves
@ 2014-08-28  1:21         ` Peng Fan
  0 siblings, 0 replies; 7+ messages in thread
From: Peng Fan @ 2014-08-28  1:21 UTC (permalink / raw)
  To: Pedro Alves, Yao Qi; +Cc: gdb



On 08/28/2014 05:58 AM, Pedro Alves wrote:
> On 08/27/2014 01:11 PM, Yao Qi wrote:
> 
>> GDB is interested in entry address, but I don't know why GDB insert
>> breakpoint there.  In GDB, command 'maintenance info breakpoints' can
>> list all the user breakpoints and internal breakpoints.  If it still
>> doesn't help, you can debug your gdb, set breakpoint
>> remote_insert_breakpoint, and check why the breakpoint is inserted at
>> 0x87800000.
> 
Breakpoint 1, do_bootz (cmdtp=0x8784cbc4 <_u_boot_list_2_cmd_2_bootz>, flag=0, 
    argc=1, argv=0xbf552a20) at common/cmd_bootm.c:1928
1928	{
(gdb) maintenance info breakpoints
Num     Type           Disp Enb Address    What
-1      shlib events   keep y   0x87800000 <_start> inf 1
1       breakpoint     keep y   0x87809580 in do_bootz 
                                           at common/cmd_bootm.c:1928 inf 1
	breakpoint already hit 2 times
> I'd guess this is a build of GDB targeting Linux, and then that
> breakpoint is the solib-event breakpoint.  One of the
> last-resort addresses solib-svr4.c tries is _start:
> 
> static const char * const bkpt_names[] =
> {
>   "_start",
> ...
> 
$arm-poky-linux-gnueabi-nm u-boot |grep start
87899130 B NetRestartWrap
87899094 b NetRestarted
8784d35c B __bss_start
87800000 T __image_copy_start
8784d35c D __rel_dyn_start
87800000 T _start

Yeah. I just objdump the elf file, but not `nm`.  symbol __image_copy_start and __start both point to 0x87800000.

Thanks all.

Regards,
Peng.
> Thanks,
> Pedro Alves
> 


^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2014-08-28  1:21 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-08-26  6:57 GDB Remote debug: Why several "$Z0,address,length" msg when only set one breakpoint? Peng Fan
2014-08-26 13:18 ` Luis Machado
2014-08-27  0:36 ` Yao Qi
2014-08-27  7:50   ` Peng Fan
2014-08-27 12:15     ` Yao Qi
2014-08-27 21:58       ` Pedro Alves
2014-08-28  1:21         ` Peng Fan

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox