* How are watchpoints handled? (remote serial)
@ 2015-11-09 22:57 Juha Aaltonen
2015-11-10 23:26 ` Juha Aaltonen
0 siblings, 1 reply; 3+ messages in thread
From: Juha Aaltonen @ 2015-11-09 22:57 UTC (permalink / raw)
To: gdb-mailing list
How should the watchpoints be handled by remote stub/server?
It seems that when 'cont'-command is given, gdb re-installs watchpoint
and sends 'c'-packet.
If the return address is the trap address, the watchpoint trigs again,
but if the address is advanced,
the access is not done at all, because the watchpoint makes exception
before the access is made.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: How are watchpoints handled? (remote serial)
2015-11-09 22:57 How are watchpoints handled? (remote serial) Juha Aaltonen
@ 2015-11-10 23:26 ` Juha Aaltonen
2015-11-10 23:39 ` Juha Aaltonen
0 siblings, 1 reply; 3+ messages in thread
From: Juha Aaltonen @ 2015-11-10 23:26 UTC (permalink / raw)
To: gdb-mailing list
Maybe that's a bug in gdb-multiarch 7.7.1?
Remote-debugging an ARM (watch g_testloc):
(This is as it should be.)
gdbarch_dump: have_nonsteppable_watchpoint = 1
w \x00]0x00008180 in __delay_169 () at ../blinky.c:211
211 g_testloc = 1;
(gdb) cont
Continuing.
Sending packet:
$m81b0,4#c8...[\x00][\x00][\x00][\x00][\x00][\x00][\x00][\x00][\x00][\x00][\x00][
r +]Ack
[$][0][0][0][0][0][0][0][0][#][8][0]Packet received: 00000000
[
w \x00]Sending packet:
$Z2,81b0,4#13...[\x00][\x00][\x00][\x00][\x00][\x00][\x00][\x00][\x00][\x00][\x00][\x00][\x00][
r +]Ack
[$][O][K][#][9][a]Packet received: OK
[
w \x00]Sending packet: $c#63...[\x00][\x00][\x00][\x00][\x00][
r +]Ack
[$][T][0][5][#][b][9]Packet received: T05
[
w \x00]Sending packet: $g#67...[\x00][\x00][\x00][\x00][\x00][
r +]Ack
[$][8][8][1][3][0][0][0][0][2][c][0][1][0][0][0][0][8][8][1][3][0][0][0][0][0][1][0][0][0][0][0][0][0][a][0][0][0][0][0][0][0][3][0][0][0][0][0][0][e][8][0][3][0][0][0][0][b][0][8][1][0][0][0][0][2][c][0][a][0][2][1][f][2][3][0][0][0][0][0][0][2][8][0][a][0][2][1][f][2][4][0][a][0][2][1][f][4][3][0][c][0][1][1][f][a][0][9][7][0][0][0][0][8][0][8][1][0][0][0][0][8][0][8][1][0][0][0][0][0][9][0][0][0][0][9][0][0][9][0][0][0][0][9][0][0][9][0][0][0][0][9][0][0][9][0][0][0][0][9][0][0][9][0][0][0][0][9][0][0][9][0][0][0][0][9][0][0][9][0][0][0][0][9][0][0][9][0][0][0][0][9][0][0][9][0][0][0][0][9][0][9][7][0][1][0][0][6][0][#][2][4]Packet
received: 881300002c01000088130000010000000a00000003000000e8030000b08100002c0a021f23000000280a021f240a021f430c011fa0970000808100008081000009000090090000900900009009000090090000900900009009000090090000900900009097010060
[
w \x00]Sending packet:
$m8180,4#9e...[\x00][\x00][\x00][\x00][\x00][\x00][\x00][\x00][\x00][\x00][\x00][
r +]Ack
[$][0][0][3][0][8][7][e][5][#][c][c]Packet received: 003087e5
[
... (lots of memory reads) ...
[
w \x00]Sending packet:
$m8180,4#9e...[\x00][\x00][\x00][\x00][\x00][\x00][\x00][\x00][\x00][\x00][\x00][
r +]Ack
[$][0][0][3][0][8][7][e][5][#][c][c]Packet received: 003087e5
[
w \x00]
Program received signal SIGTRAP, Trace/breakpoint trap.
Sending packet:
$z2,81b0,4#33...[\x00][\x00][\x00][\x00][\x00][\x00][\x00][\x00][\x00][\x00][\x00][\x00][\x00][
r +]Ack
[$][O][K][#][9][a]Packet received: OK
[
w \x00]0x00008180 in __delay_169 () at ../blinky.c:211
211 g_testloc = 1;
(gdb)
No stepping over watchpoint.
On Tue, Nov 10, 2015 at 12:57 AM, Juha Aaltonen <turbopultti@gmail.com> wrote:
> How should the watchpoints be handled by remote stub/server?
> It seems that when 'cont'-command is given, gdb re-installs watchpoint
> and sends 'c'-packet.
>
> If the return address is the trap address, the watchpoint trigs again,
> but if the address is advanced,
> the access is not done at all, because the watchpoint makes exception
> before the access is made.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: How are watchpoints handled? (remote serial)
2015-11-10 23:26 ` Juha Aaltonen
@ 2015-11-10 23:39 ` Juha Aaltonen
0 siblings, 0 replies; 3+ messages in thread
From: Juha Aaltonen @ 2015-11-10 23:39 UTC (permalink / raw)
To: gdb-mailing list
With single-step the same thing - installs both watchpoint and breakpoint.
w \x00]0x00008180 in __delay_169 () at ../blinky.c:211
211 g_testloc = 1;
(gdb) stepi
Sending packet:
$m81b0,4#c8...[\x00][\x00][\x00][\x00][\x00][\x00][\x00][\x00][\x00][\x00][\x00][
r +]Ack
[$][0][0][0][0][0][0][0][0][#][8][0]Packet received: 00000000
[
w \x00]Sending packet:
$Z2,81b0,4#13...[\x00][\x00][\x00][\x00][\x00][\x00][\x00][\x00][\x00][\x00][\x00][\x00][\x00][
r +]Ack
[$][O][K][#][9][a]Packet received: OK
[
w \x00]Sending packet: $p19#da...[\x00][\x00][\x00][\x00][\x00][\x00][\x00][
r +]Ack
[$][9][7][0][1][0][0][6][0][#][9][7]Packet received: 97010060
[
w \x00]Sending packet:
$m8180,4#9e...[\x00][\x00][\x00][\x00][\x00][\x00][\x00][\x00][\x00][\x00][\x00][
r +]Ack
[$][0][0][3][0][8][7][e][5][#][c][c]Packet received: 003087e5
[
w \x00]Sending packet:
$m8180,4#9e...[\x00][\x00][\x00][\x00][\x00][\x00][\x00][\x00][\x00][\x00][\x00][
r +]Ack
[$][0][0][3][0][8][7][e][5][#][c][c]Packet received: 003087e5
[
w \x00]Sending packet:
$Z0,8184,4#eb...[\x00][\x00][\x00][\x00][\x00][\x00][\x00][\x00][\x00][\x00][\x00][\x00][\x00][
r +]Ack
[$][O][K][#][9][a]Packet received: OK
[
w \x00]Sending packet: $c#63...[\x00][\x00][\x00][\x00][\x00][
r +]Ack
[$][T][0][5][#][b][9]Packet received: T05
[
w \x00]Sending packet: $g#67...[\x00][\x00][\x00][\x00][\x00][
r +]Ack
[$][8][8][1][3][0][0][0][0][2][c][0][1][0][0][0][0][8][8][1][3][0][0][0][0][0][1][0][0][0][0][0][0][0][a][0][0][0][0][0][0][0][3][0][0][0][0][0][0][e][8][0][3][0][0][0][0][b][0][8][1][0][0][0][0][2][c][0][a][0][2][1][f][2][3][0][0][0][0][0][0][2][8][0][a][0][2][1][f][2][4][0][a][0][2][1][f][3][3][0][c][0][1][1][f][a][0][9][7][0][0][0][0][8][0][8][1][0][0][0][0][8][0][8][1][0][0][0][0][0][9][0][0][0][0][9][0][0][9][0][0][0][0][9][0][0][9][0][0][0][0][9][0][0][9][0][0][0][0][9][0][0][9][0][0][0][0][9][0][0][9][0][0][0][0][9][0][0][9][0][0][0][0][9][0][0][9][0][0][0][0][9][0][0][9][0][0][0][0][9][0][9][7][0][1][0][0][6][0][#][2][3]Packet
received: 881300002c01000088130000010000000a00000003000000e8030000b08100002c0a021f23000000280a021f240a021f330c011fa0970000808100008081000009000090090000900900009009000090090000900900009009000090090000900900009097010060
[
w \x00]Sending packet:
$m8180,4#9e...[\x00][\x00][\x00][\x00][\x00][\x00][\x00][\x00][\x00][\x00][\x00][
r +]Ack
[$][0][0][3][0][8][7][e][5][#][c][c]Packet received: 003087e5
... (lots of memory reads) ...
[
w \x00]Sending packet:
$m8180,4#9e...[\x00][\x00][\x00][\x00][\x00][\x00][\x00][\x00][\x00][\x00][\x00][
r +]Ack
[$][0][0][3][0][8][7][e][5][#][c][c]Packet received: 003087e5
[
w \x00]Sending packet:
$z0,8184,4#0b...[\x00][\x00][\x00][\x00][\x00][\x00][\x00][\x00][\x00][\x00][\x00][\x00][\x00][
r +]Ack
[$][O][K][#][9][a]Packet received: OK
[
w \x00]Sending packet:
$z2,81b0,4#33...[\x00][\x00][\x00][\x00][\x00][\x00][\x00][\x00][\x00][\x00][\x00][\x00][\x00][
r +]Ack
[$][O][K][#][9][a]Packet received: OK
[
w \x00]0x00008180 211 g_testloc = 1;
(gdb)
The g_testloc never gets set to 1.
On Wed, Nov 11, 2015 at 1:26 AM, Juha Aaltonen <turbopultti@gmail.com> wrote:
> Maybe that's a bug in gdb-multiarch 7.7.1?
> Remote-debugging an ARM (watch g_testloc):
>
> (This is as it should be.)
> gdbarch_dump: have_nonsteppable_watchpoint = 1
>
>
> w \x00]0x00008180 in __delay_169 () at ../blinky.c:211
> 211 g_testloc = 1;
> (gdb) cont
> Continuing.
> Sending packet:
> $m81b0,4#c8...[\x00][\x00][\x00][\x00][\x00][\x00][\x00][\x00][\x00][\x00][\x00][
> r +]Ack
> [$][0][0][0][0][0][0][0][0][#][8][0]Packet received: 00000000
> [
> w \x00]Sending packet:
> $Z2,81b0,4#13...[\x00][\x00][\x00][\x00][\x00][\x00][\x00][\x00][\x00][\x00][\x00][\x00][\x00][
> r +]Ack
> [$][O][K][#][9][a]Packet received: OK
> [
> w \x00]Sending packet: $c#63...[\x00][\x00][\x00][\x00][\x00][
> r +]Ack
> [$][T][0][5][#][b][9]Packet received: T05
> [
> w \x00]Sending packet: $g#67...[\x00][\x00][\x00][\x00][\x00][
> r +]Ack
> [$][8][8][1][3][0][0][0][0][2][c][0][1][0][0][0][0][8][8][1][3][0][0][0][0][0][1][0][0][0][0][0][0][0][a][0][0][0][0][0][0][0][3][0][0][0][0][0][0][e][8][0][3][0][0][0][0][b][0][8][1][0][0][0][0][2][c][0][a][0][2][1][f][2][3][0][0][0][0][0][0][2][8][0][a][0][2][1][f][2][4][0][a][0][2][1][f][4][3][0][c][0][1][1][f][a][0][9][7][0][0][0][0][8][0][8][1][0][0][0][0][8][0][8][1][0][0][0][0][0][9][0][0][0][0][9][0][0][9][0][0][0][0][9][0][0][9][0][0][0][0][9][0][0][9][0][0][0][0][9][0][0][9][0][0][0][0][9][0][0][9][0][0][0][0][9][0][0][9][0][0][0][0][9][0][0][9][0][0][0][0][9][0][0][9][0][0][0][0][9][0][9][7][0][1][0][0][6][0][#][2][4]Packet
> received: 881300002c01000088130000010000000a00000003000000e8030000b08100002c0a021f23000000280a021f240a021f430c011fa0970000808100008081000009000090090000900900009009000090090000900900009009000090090000900900009097010060
> [
> w \x00]Sending packet:
> $m8180,4#9e...[\x00][\x00][\x00][\x00][\x00][\x00][\x00][\x00][\x00][\x00][\x00][
> r +]Ack
> [$][0][0][3][0][8][7][e][5][#][c][c]Packet received: 003087e5
> [
> ... (lots of memory reads) ...
> [
> w \x00]Sending packet:
> $m8180,4#9e...[\x00][\x00][\x00][\x00][\x00][\x00][\x00][\x00][\x00][\x00][\x00][
> r +]Ack
> [$][0][0][3][0][8][7][e][5][#][c][c]Packet received: 003087e5
> [
> w \x00]
> Program received signal SIGTRAP, Trace/breakpoint trap.
> Sending packet:
> $z2,81b0,4#33...[\x00][\x00][\x00][\x00][\x00][\x00][\x00][\x00][\x00][\x00][\x00][\x00][\x00][
> r +]Ack
> [$][O][K][#][9][a]Packet received: OK
> [
> w \x00]0x00008180 in __delay_169 () at ../blinky.c:211
> 211 g_testloc = 1;
> (gdb)
>
>
> No stepping over watchpoint.
>
>
> On Tue, Nov 10, 2015 at 12:57 AM, Juha Aaltonen <turbopultti@gmail.com> wrote:
>> How should the watchpoints be handled by remote stub/server?
>> It seems that when 'cont'-command is given, gdb re-installs watchpoint
>> and sends 'c'-packet.
>>
>> If the return address is the trap address, the watchpoint trigs again,
>> but if the address is advanced,
>> the access is not done at all, because the watchpoint makes exception
>> before the access is made.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2015-11-10 23:39 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-11-09 22:57 How are watchpoints handled? (remote serial) Juha Aaltonen
2015-11-10 23:26 ` Juha Aaltonen
2015-11-10 23:39 ` Juha Aaltonen
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).