public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
* Confused by watchpoints on remote protocol
@ 2022-08-06 20:42 Denio, Mike
  2022-08-07  6:25 ` Denio, Mike
  0 siblings, 1 reply; 5+ messages in thread
From: Denio, Mike @ 2022-08-06 20:42 UTC (permalink / raw)
  To: gdb

In GDB 11.2 for RISCV, I am trying to support hardware watchpoints. I think I'm close, but I have 2 questions:

1. I noticed that whether or not GDB will even attempt to use a hardware watch point depends on the how the command it entered. For example:

(gdb)  watch *(uint32_t *)(0x80000018)
Hardware watchpoint 1: *(uint32_t *)(0x80000018)
(gdb)  watch (uint32_t)ram_table
Watchpoint 2: (uint32_t)ram_table
(gdb) i b
Num     Type           Disp Enb Address    What
1       hw watchpoint  keep y              *(uint32_t *)(0x80000018)
2       watchpoint     keep y              (uint32_t)ram_table

When I enter is as "watch *(uint32_t *)(0x80000018)", a hardware watchpoint is used, but when I enter it as
"watch (uint32_t)ram_table", a soft watchpoint is used.

I don't understand this. How can I tell GDB to always use a hardware watchpoint?

Also, FYI, the order doesn't matter (it's not as if GDB assumes only 1 hardware watchpoint). Below we see GDB immediately uses a software watchpoint:

(gdb) watch (uint32_t)ram_table
Watchpoint 1: (uint32_t)ram_table
(gdb) watch *(uint32_t *)(0x80000018)
Hardware watchpoint 2: *(uint32_t *)(0x80000018)
(gdb) i b
Num     Type           Disp Enb Address    What
1       watchpoint     keep y              (uint32_t)ram_table
2       hw watchpoint  keep y              *(uint32_t *)(0x80000018)

Now that I think about it, how do I tell GDB how many hardware watchpoints I support?

2. Also a second related question. I noticed that unlike breakpoints, GDB will not remove, single step past, and then replace hardware watchpoints. Is it always assumed that hardware watchpoints break AFTER the operation in question? It makes sense to break after the operation for writes since the user wants to watch a value change, but it wasn't obvious to me for read and access watchpoints. Should all of them break on the following instruction?


Thanks in advance for any help. Please keep my e-mail on the reply as I am not subscribed.

Mike


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

* RE: Confused by watchpoints on remote protocol
  2022-08-06 20:42 Confused by watchpoints on remote protocol Denio, Mike
@ 2022-08-07  6:25 ` Denio, Mike
  2022-08-07  7:23   ` Andreas Schwab
  0 siblings, 1 reply; 5+ messages in thread
From: Denio, Mike @ 2022-08-07  6:25 UTC (permalink / raw)
  To: gdb

You can ignore my second question in the original e-mail. I was not reporting the stop correctly. GDB behavior was as expected once I fixed that.

The only question I have is that when I type:
"watch *(uint32_t *)(0x80000018)"
I get a hardware watch point.

And when I type:
"watch (uint32_t)ram_table"
I get a software watch point.

Anyone know why? And how to change it to be always hardware?

Thanks,
Mike

From: Denio, Mike <>
Sent: Saturday, August 06, 2022 3:43 PM
To: 'gdb@sourceware.org' <gdb@sourceware.org>
Subject: Confused by watchpoints on remote protocol

In GDB 11.2 for RISCV, I am trying to support hardware watchpoints. I think I'm close, but I have 2 questions:

1. I noticed that whether or not GDB will even attempt to use a hardware watch point depends on the how the command it entered. For example:

(gdb)  watch *(uint32_t *)(0x80000018)
Hardware watchpoint 1: *(uint32_t *)(0x80000018)
(gdb)  watch (uint32_t)ram_table
Watchpoint 2: (uint32_t)ram_table
(gdb) i b
Num     Type           Disp Enb Address    What
1       hw watchpoint  keep y              *(uint32_t *)(0x80000018)
2       watchpoint     keep y              (uint32_t)ram_table

When I enter is as "watch *(uint32_t *)(0x80000018)", a hardware watchpoint is used, but when I enter it as
"watch (uint32_t)ram_table", a soft watchpoint is used.

I don't understand this. How can I tell GDB to always use a hardware watchpoint?

Also, FYI, the order doesn't matter (it's not as if GDB assumes only 1 hardware watchpoint). Below we see GDB immediately uses a software watchpoint:

(gdb) watch (uint32_t)ram_table
Watchpoint 1: (uint32_t)ram_table
(gdb) watch *(uint32_t *)(0x80000018)
Hardware watchpoint 2: *(uint32_t *)(0x80000018)
(gdb) i b
Num     Type           Disp Enb Address    What
1       watchpoint     keep y              (uint32_t)ram_table
2       hw watchpoint  keep y              *(uint32_t *)(0x80000018)

Now that I think about it, how do I tell GDB how many hardware watchpoints I support?

2. Also a second related question. I noticed that unlike breakpoints, GDB will not remove, single step past, and then replace hardware watchpoints. Is it always assumed that hardware watchpoints break AFTER the operation in question? It makes sense to break after the operation for writes since the user wants to watch a value change, but it wasn't obvious to me for read and access watchpoints. Should all of them break on the following instruction?


Thanks in advance for any help. Please keep my e-mail on the reply as I am not subscribed.

Mike


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

* Re: Confused by watchpoints on remote protocol
  2022-08-07  6:25 ` Denio, Mike
@ 2022-08-07  7:23   ` Andreas Schwab
  2022-08-07  7:34     ` [EXTERNAL] " Denio, Mike
  0 siblings, 1 reply; 5+ messages in thread
From: Andreas Schwab @ 2022-08-07  7:23 UTC (permalink / raw)
  To: Denio, Mike via Gdb; +Cc: Denio, Mike

On Aug 07 2022, Denio, Mike via Gdb wrote:

> The only question I have is that when I type:
> "watch *(uint32_t *)(0x80000018)"
> I get a hardware watch point.
>
> And when I type:
> "watch (uint32_t)ram_table"
> I get a software watch point.

What is ram_table?

> Anyone know why? And how to change it to be always hardware?

Try looking at breakpoint.c:can_use_hardware_watchpoint.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

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

* RE: [EXTERNAL] Re: Confused by watchpoints on remote protocol
  2022-08-07  7:23   ` Andreas Schwab
@ 2022-08-07  7:34     ` Denio, Mike
  2022-08-07 14:43       ` Denio, Mike
  0 siblings, 1 reply; 5+ messages in thread
From: Denio, Mike @ 2022-08-07  7:34 UTC (permalink / raw)
  To: Andreas Schwab, Denio, Mike via Gdb

ram_table was just a symbol I created in assembly.

Its really odd, and its not the symbol itself. For example:

(gdb) watch (uint32_t)ram_table
Watchpoint 1: (uint32_t)ram_table
(gdb) watch *(uint32_t *)&ram_table
Hardware watchpoint 2: *(uint32_t *)&ram_table
(gdb) i b
Num     Type           Disp Enb Address    What
1       watchpoint     keep y              (uint32_t)ram_table
2       hw watchpoint  keep y              *(uint32_t *)&ram_table

I can see both of these variants "watching" the exact same address.

Maybe you are onto something however. I'll try it with a compiled C program and see if the behavior is any different.

Thanks,
Mike

-----Original Message-----
From: Andreas Schwab <schwab@linux-m68k.org> 
Sent: Sunday, August 07, 2022 2:24 AM
To: Denio, Mike via Gdb <gdb@sourceware.org>
Cc: Denio, Mike <miked@ti.com>
Subject: [EXTERNAL] Re: Confused by watchpoints on remote protocol

On Aug 07 2022, Denio, Mike via Gdb wrote:

> The only question I have is that when I type:
> "watch *(uint32_t *)(0x80000018)"
> I get a hardware watch point.
>
> And when I type:
> "watch (uint32_t)ram_table"
> I get a software watch point.

What is ram_table?

> Anyone know why? And how to change it to be always hardware?

Try looking at breakpoint.c:can_use_hardware_watchpoint.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

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

* RE: [EXTERNAL] Re: Confused by watchpoints on remote protocol
  2022-08-07  7:34     ` [EXTERNAL] " Denio, Mike
@ 2022-08-07 14:43       ` Denio, Mike
  0 siblings, 0 replies; 5+ messages in thread
From: Denio, Mike @ 2022-08-07 14:43 UTC (permalink / raw)
  To: Andreas Schwab, Denio, Mike via Gdb

I verified with a compiled C program, the watch always uses a hardware watch.

Not sure what it doesn't like about my assembly, but it obviously has nothing to do with my GDB server, so pressing on ...

Thanks for the suggestion.

Mike

-----Original Message-----
From: Denio, Mike <> 
Sent: Sunday, August 07, 2022 2:34 AM
To: 'Andreas Schwab' <schwab@linux-m68k.org>; Denio, Mike via Gdb <gdb@sourceware.org>
Subject: RE: [EXTERNAL] Re: Confused by watchpoints on remote protocol

ram_table was just a symbol I created in assembly.

Its really odd, and its not the symbol itself. For example:

(gdb) watch (uint32_t)ram_table
Watchpoint 1: (uint32_t)ram_table
(gdb) watch *(uint32_t *)&ram_table
Hardware watchpoint 2: *(uint32_t *)&ram_table
(gdb) i b
Num     Type           Disp Enb Address    What
1       watchpoint     keep y              (uint32_t)ram_table
2       hw watchpoint  keep y              *(uint32_t *)&ram_table

I can see both of these variants "watching" the exact same address.

Maybe you are onto something however. I'll try it with a compiled C program and see if the behavior is any different.

Thanks,
Mike

-----Original Message-----
From: Andreas Schwab <schwab@linux-m68k.org> 
Sent: Sunday, August 07, 2022 2:24 AM
To: Denio, Mike via Gdb <gdb@sourceware.org>
Cc: Denio, Mike <miked@ti.com>
Subject: [EXTERNAL] Re: Confused by watchpoints on remote protocol

On Aug 07 2022, Denio, Mike via Gdb wrote:

> The only question I have is that when I type:
> "watch *(uint32_t *)(0x80000018)"
> I get a hardware watch point.
>
> And when I type:
> "watch (uint32_t)ram_table"
> I get a software watch point.

What is ram_table?

> Anyone know why? And how to change it to be always hardware?

Try looking at breakpoint.c:can_use_hardware_watchpoint.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

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

end of thread, other threads:[~2022-08-07 14:43 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-08-06 20:42 Confused by watchpoints on remote protocol Denio, Mike
2022-08-07  6:25 ` Denio, Mike
2022-08-07  7:23   ` Andreas Schwab
2022-08-07  7:34     ` [EXTERNAL] " Denio, Mike
2022-08-07 14:43       ` Denio, Mike

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).