Re: Why no hwatch command in gdb ?

Re: Why no hwatch command in gdb ?

[paawan oza]

gdb uses HW debug registers HW support is there; and most of the processors have 

it.

just need to change configuration internal to gdb;

set can-use-hw-watchpoint.. 1


then when you watch; it will set as many watchpoints as many debug registers 
available.

regards,
Oza.



----- Original Message ----
From: robert song <robertsong.japan@gmail.com>
To: gdb@sourceware.org
Sent: Thu, March 10, 2011 12:55:18 PM
Subject: Why no hwatch command in gdb ?

Hi, everyone.

In gdb command line, we can use break or hbreak to set breakpoint or
hardware breakpoint.

But I can only find watch command without hardware watch command, so
why watchpoint and breakpoint command are not united?

Regards,
  robert


      

Why no hwatch command in gdb ?

[robert song]

Hi, everyone.

In gdb command line, we can use break or hbreak to set breakpoint or
hardware breakpoint.

But I can only find watch command without hardware watch command, so
why watchpoint and breakpoint command are not united?

Regards,
  robert

Re: Why no hwatch command in gdb ?

[Jan Kratochvil]

On Thu, 10 Mar 2011 08:25:18 +0100, robert song wrote:
> In gdb command line, we can use break or hbreak to set breakpoint or
> hardware breakpoint.
> 
> But I can only find watch command without hardware watch command, so
> why watchpoint and breakpoint command are not united?

Watchpoints are normally created by default as hardware ones.  They should
fallback to their software variants when you get out of the number of debug
registers but that does not work well now.

You can request hardware vs. software watchpoints by using:
(gdb) help set can-use-hw-watchpoints 
Set debugger's willingness to use watchpoint hardware.
If zero, gdb will not use hardware for new watchpoints, even if
such is available.  (However, any hardware watchpoints that were
created before setting this to nonzero, will continue to use watchpoint
hardware.)

The difference is that software breakpoints are very cheap so GDB does not even
attempt to create hardware breakpoints.  While software watchpoints are very
expensive so - in fact GDB does not normally try to fallback to software ones.
When you have to use software watchpoints it is commonly even not viable to
wait for so long.


Thanks,
Jan

Re: Why no hwatch command in gdb ?

[robert song]

Hi, Jan,

On 3/10/11, Jan Kratochvil <jan.kratochvil@redhat.com> wrote:
> Watchpoints are normally created by default as hardware ones.  They should
> fallback to their software variants when you get out of the number of debug
> registers but that does not work well now.
>
"does not work well now" means ?

> You can request hardware vs. software watchpoints by using:
> (gdb) help set can-use-hw-watchpoints
> Set debugger's willingness to use watchpoint hardware.
> If zero, gdb will not use hardware for new watchpoints, even if
> such is available.  (However, any hardware watchpoints that were
> created before setting this to nonzero, will continue to use watchpoint
> hardware.)
>
> The difference is that software breakpoints are very cheap so GDB does not
> even
> attempt to create hardware breakpoints.  While software watchpoints are very
> expensive so - in fact GDB does not normally try to fallback to software
> ones.
> When you have to use software watchpoints it is commonly even not viable to
> wait for so long.

The problem is that sometimes I just want to set only hardware
watchpoints, and don't want to set software watchpoints. But the
watchpoint will be changed to software ones if hardware watchpoints
are exceeded, and if I have command like hwatch, I can avoid it.

Regards,
  robert

Re: Why no hwatch command in gdb ?

[Jan Kratochvil]

Hi Robert,

On Thu, 10 Mar 2011 11:09:23 +0100, robert song wrote:
> On 3/10/11, Jan Kratochvil <jan.kratochvil@redhat.com> wrote:
> > Watchpoints are normally created by default as hardware ones.  They should
> > fallback to their software variants when you get out of the number of debug
> > registers but that does not work well now.
> >
> "does not work well now" means ?

GNU gdb (GDB) 7.2.50.20110310-cvs
This GDB was configured as "x86_64-unknown-linux-gnu".
(gdb) watch gdb_stdout
Hardware watchpoint 2: gdb_stdout
(gdb) watch gdb_stderr
Hardware watchpoint 3: gdb_stderr
(gdb) watch gdb_stdlog
Hardware watchpoint 4: gdb_stdlog
(gdb) watch gdb_stdin
Hardware watchpoint 5: gdb_stdin
(gdb) watch gdb_stdtargin
Hardware watchpoint 6: gdb_stdtargin
(gdb) continue 
Continuing.
Warning:
Could not insert hardware watchpoint 5.
Could not insert hardware breakpoints:
You may have requested too many hardware breakpoints/watchpoints.
(gdb) 


> The problem is that sometimes I just want to set only hardware
> watchpoints, and don't want to set software watchpoints. But the
> watchpoint will be changed to software ones if hardware watchpoints
> are exceeded,

When at least one watchpoint is a software one GDB has to start single-stepping
the inferior.  At that moment it does not matter whether some additional
watchpoints are software or hardware ones.


Thanks,
Jan

Re: Why no hwatch command in gdb ?

[Eli Zaretskii]

> Date: Thu, 10 Mar 2011 11:34:09 +0100
> From: Jan Kratochvil <jan.kratochvil@redhat.com>
> Cc: gdb@sourceware.org
> 
> > "does not work well now" means ?
> 
> GNU gdb (GDB) 7.2.50.20110310-cvs
> This GDB was configured as "x86_64-unknown-linux-gnu".
> (gdb) watch gdb_stdout
> Hardware watchpoint 2: gdb_stdout
> (gdb) watch gdb_stderr
> Hardware watchpoint 3: gdb_stderr
> (gdb) watch gdb_stdlog
> Hardware watchpoint 4: gdb_stdlog
> (gdb) watch gdb_stdin
> Hardware watchpoint 5: gdb_stdin
> (gdb) watch gdb_stdtargin
> Hardware watchpoint 6: gdb_stdtargin
> (gdb) continue 
> Continuing.
> Warning:
> Could not insert hardware watchpoint 5.
> Could not insert hardware breakpoints:
> You may have requested too many hardware breakpoints/watchpoints.
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Well, you did, didn't you?

If you expect GDB to know up front that they are too many, this is
hard to impossible with today's architecture, because only when the
watchpoints are inserted by the target, it is possible to know whether
there are enough resources for that.

(At least that's how things were back when I hacked x86 watchpoints.)

Re: Why no hwatch command in gdb ?

[Joel Brobecker]

> If you expect GDB to know up front that they are too many, this is
> hard to impossible with today's architecture, because only when the
> watchpoints are inserted by the target, it is possible to know whether
> there are enough resources for that.
> 
> (At least that's how things were back when I hacked x86 watchpoints.)

I've always been confused by the way watchpoints are supported in
GDB, depending on the target platform, etc.  I think there was
a recent change that made us insert the watchpoint immediately,
as a way to check whether we have resources or not.  I don't
know how much this helps in practice.

-- 
Joel

Re: Why no hwatch command in gdb ?

[Pedro Alves]

On Thursday 10 March 2011 11:34:21, Joel Brobecker wrote:
> I think there was a recent change that made us insert the watchpoint 
> immediately, as a way to check whether we have resources or not.  I don't
> know how much this helps in practice.

I think you're wishful thinking.  I proposed that (*) while reviewing the
PPC ranged watchpoints support as a way of getting rid of the (mostly
broken) watchpoint resources accounting mechanism, but it was
never implemented.

(*) - most probably others have done so too before me.

-- 
Pedro Alves

Re: Why no hwatch command in gdb ?

[Jan Kratochvil]

On Thu, 10 Mar 2011 12:26:41 +0100, Eli Zaretskii wrote:
> > You may have requested too many hardware breakpoints/watchpoints.
>   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Well, you did, didn't you?

I did request _any_ watchpoint.  `watch' sometimes creates hardware ones,
sometimes software ones.  In fact on some arches (ppc?) it even works AFAIK.
It is GDB's fault it did not choose the right wathcpoint kind.


> If you expect GDB to know up front that they are too many, this is
> hard to impossible with today's architecture, because only when the
> watchpoints are inserted by the target, it is possible to know whether
> there are enough resources for that.

You are right the watchpoints infrastructure is very broken now.  But it is
being discussed for upstream kernel that the DR registers access via
PTRACE_POKEUSER is broken anyway and GDB should use the existing hardware
watchpoints support in Linux kernel perf via some higher level interface
(still probably through the ptrace syscall).


Thanks,
Jan

Re: Why no hwatch command in gdb ?

[Frank Ch. Eigler]

Jan Kratochvil <jan.kratochvil@redhat.com> writes:

> [...]
> But it being discussed for upstream kernel that the DR registers access via
> PTRACE_POKEUSER is broken anyway and GDB should use the existing hardware
> watchpoints support in Linux kernel perf via some higher level interface
> (still probably through the ptrace syscall).

While a new kernel interface wouldn't be able to fabricate any
hardware-watchpoint resources after they're exhausted, a properly
designed one should be able to evaluate software watchpoints much
faster.

- FChE

Re: Why no hwatch command in gdb ?

[robert song]

Hi, Jan,

On 3/10/11, Jan Kratochvil <jan.kratochvil@redhat.com> wrote:
> GNU gdb (GDB) 7.2.50.20110310-cvs
> This GDB was configured as "x86_64-unknown-linux-gnu".
> (gdb) watch gdb_stdout
> Hardware watchpoint 2: gdb_stdout
> (gdb) watch gdb_stderr
> Hardware watchpoint 3: gdb_stderr
> (gdb) watch gdb_stdlog
> Hardware watchpoint 4: gdb_stdlog
> (gdb) watch gdb_stdin
> Hardware watchpoint 5: gdb_stdin
> (gdb) watch gdb_stdtargin
> Hardware watchpoint 6: gdb_stdtargin
> (gdb) continue
> Continuing.
> Warning:
> Could not insert hardware watchpoint 5.
> Could not insert hardware breakpoints:
> You may have requested too many hardware breakpoints/watchpoints.
> (gdb)

Well, I am confused with the gdb hardware watchpoint support in x86
arch.

I tested it in a ARM board. Now the kernel can support up to 1
hardware watchpoint and 6 hardware breakpoints.

(gdb) hbreak main
No hardware breakpoint support in the target.
(gdb) b main
Breakpoint 2 at 0x8364: file /tmp/helloworld.c, line 7.
(gdb) run
Starting program: /tmp/helloworld

Breakpoint 2, main () at /tmp/helloworld.c:7
7         i=1;
(gdb) watch i
Hardware watchpoint 3: i
(gdb) watch i
Watchpoint 4: i
(gdb) hbreak 8
Hardware assisted breakpoint 5 at 0x8370: file /tmp/helloworld.c, line 8.
(gdb) hbreak 9
Hardware assisted breakpoint 6 at 0x837c: file /tmp/helloworld.c, line 9.
(gdb) hbreak 10
Hardware assisted breakpoint 7 at 0x8388: file /tmp/helloworld.c, line 10.
(gdb) hbreak 11
Hardware assisted breakpoint 8 at 0x8394: file /tmp/helloworld.c, line 11.
(gdb) hbreak 12
Hardware assisted breakpoint 9 at 0x83a0: file /tmp/helloworld.c, line 12.
(gdb) hbreak 13
Hardware assisted breakpoint 10 at 0x83ac: file /tmp/helloworld.c, line 13.
(gdb) hbreak 14
Hardware breakpoints used exceeds limit.
(gdb) hbreak 15
Hardware breakpoints used exceeds limit.

Firstly, before the program run, we can not set the hardware
breakpoint. For gdb use ptrace to get the debug register information,
and thread id is needed.

hardware watchpoint can only be set to 1, and hardware breakpoint can
be set to 6. If more than 6, gdb will complain with "Hardware
breakpoints used exceeds limit."

So I think it works fine in the arm arch.

But in x86, I took a look at my CentOS 5.5 7.0.1-23.el5.
We can set the hardware breakpoint before program runs, it's not the
standard gdb function. There is a patch named
gdb-bz541866-rwatch-before-run.patch, in the patch,
target_can_use_hardware_watchpoint is forced to be 1.

--- /dev/null
+++ b/gdb/config/ia64/nm-linux.h
@@ -0,0 +1,28 @@
+/* Native support for GNU/Linux ia64.
+
+   Copyright 2010 Free Software Foundation, Inc.
+
+   This file is part of GDB.
+
+   This program is free software; you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 3 of the License, or
+   (at your option) any later version.
+
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+   GNU General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with this program.  If not, see <http://www.gnu.org/licenses/>.  */
+
+#ifndef NM_LINUX_H
+#define NM_LINUX_H
+
+#include "config/nm-linux.h"
+
+/* Red Hat backward compatibility with gdb-6.8.  */
+#define target_can_use_hardware_watchpoint(type, cnt, ot) 1
+
+#endif /* NM_LINUX_H */
--- a/gdb/target.h
+++ b/gdb/target.h
@@ -1257,8 +1257,10 @@ extern char *normal_pid_to_str (ptid_t ptid);
    bp_hardware_breakpoint.  CNT is the number of such watchpoints used so far
    (including this one?).  OTHERTYPE is who knows what...  */

+#ifndef target_can_use_hardware_watchpoint
 #define target_can_use_hardware_watchpoint(TYPE,CNT,OTHERTYPE) \
  (*current_target.to_can_use_hw_breakpoint) (TYPE, CNT, OTHERTYPE);
+#endif

So the problem is because of the previous patch of this distribution
?????

Regards,
  robert

Re: Why no hwatch command in gdb ?

[Jan Kratochvil]

Hi Robert,

On Thu, 10 Mar 2011 13:18:06 +0100, robert song wrote:
> Well, I am confused with the gdb hardware watchpoint support in x86
> arch.

x86* is special as its debug registers capabilities are complicated - it can
watch 1/2/4/8 bytes and there are 4 of them.  GDB supports aliasing, so if you
watch string[0] and string[1] GDB will merge it and will watch 2 bytes at
&string[0].

Upper layers GDB do not support any target-specific watchpoint tricks, so i386
pretends it can always merge them somehow - and if it latter cannot it will
fail.  See i386_can_use_hw_breakpoint.


> I tested it in a ARM board. Now the kernel can support up to 1
> hardware watchpoint and 6 hardware breakpoints.

As ARM does suppors only a single register size the aliasing does not need to
be supported on ARM, therefore the hardware watchpoints count limitations
works on ARM (in general, I do not know ARM).


> Firstly, before the program run, we can not set the hardware breakpoint.
...
> But in x86, I took a look at my CentOS 5.5 7.0.1-23.el5.
> We can set the hardware breakpoint before program runs, it's not the
> standard gdb function. There is a patch named
> gdb-bz541866-rwatch-before-run.patch, in the patch,
> target_can_use_hardware_watchpoint is forced to be 1.

http://pkgs.fedoraproject.org/gitweb/?p=gdb.git;a=blob;f=gdb-bz541866-rwatch-before-run.patch;hb=f15/master

FSF GDB started to disallow hardware watchpoints such as `awatch'/`rwatch'
since one point.  As it was considered a regression by the users I had to
"temporarily" revert the upstream change and put there the older hack.
The watchpoints framework needs to be improved to support this a sane way.


> So the problem is because of the previous patch of this distribution
> ?????

I do not know on which arch which specific problem you want to solve now.


Thanks,
Jan

Re: Why no hwatch command in gdb ?

[Philippe Waroquiers]

On the side of 'hardware' watchpoints limitations:
I am busy embedding a gdbserver inside Valgrind (target is
to integrate it in April, but more review activity is still needed).

As part of this work, unlimited "simulated hardware watchpoints"
have been implemented on top of the "address access/validity bits"
of Valgrind memcheck tool.

These simulated hardware watchpoints are of course a lot
slower than real hardware watchpoint, but they are faster
than gdb "single stepping" watchpoints (and more over,
you have unlimited "read watchpoints").

I only encountered a small problem with gdb "remote":
There is a gdb command to configure the nr of remote hardware watchpoint
but there is no command to configure the length for an hardware
watchpoint: e.g. for i386, gdb remote "hardcodes" the length to 4 bytes
(which looks wrong btw, as the real hw can go up to 8 bytes I believe).

So, I have in a corner a patch implementing
   'set remote hardware-watchpoint-length-limit'
to configure the max length limit of an hw watchpoint.

With this patch + Valgrind gdbserver, you can e.g. read or write or access
watch many and/or big memory ranges, paying "only" the "limited"
Valgrind memcheck overhead (still big overhead, but significantly
faster than pure gdb software watchpoint).

I believe it would be nice to add this new command in gdb.

If you want more info about the gdbserver in Valgrind, I can give more
(I expect to output a new improved beta version of the Valgrind gdbserver
patch in the coming days).

Philippe

Re: Why no hwatch command in gdb ?

[Tom Tromey]

>>>>> "Philippe" == Philippe Waroquiers <philippe.waroquiers@skynet.be> writes:

Philippe> On the side of 'hardware' watchpoints limitations:
Philippe> I am busy embedding a gdbserver inside Valgrind (target is
Philippe> to integrate it in April, but more review activity is still needed).

Delightful.

Philippe> I only encountered a small problem with gdb "remote": There is
Philippe> a gdb command to configure the nr of remote hardware
Philippe> watchpoint but there is no command to configure the length for
Philippe> an hardware watchpoint: e.g. for i386, gdb remote "hardcodes"
Philippe> the length to 4 bytes (which looks wrong btw, as the real hw
Philippe> can go up to 8 bytes I believe).

Philippe> So, I have in a corner a patch implementing
Philippe>   'set remote hardware-watchpoint-length-limit'
Philippe> to configure the max length limit of an hw watchpoint.

Philippe> I believe it would be nice to add this new command in gdb.

As far as I understand it, this sounds ok.

Why can't this be negotiated between gdb and the remote?
Then the in-valgrind gdbserver could just report unlimited and the user
wouldn't have to fool around.

Philippe> If you want more info about the gdbserver in Valgrind, I can
Philippe> give more (I expect to output a new improved beta version of
Philippe> the Valgrind gdbserver patch in the coming days).

If you send out announcements, feel free to CC this list.

Tom

Re: Why no hwatch command in gdb ?

[Philippe Waroquiers]

> Why can't this be negotiated between gdb and the remote?
> Then the in-valgrind gdbserver could just report unlimited and the user
> wouldn't have to fool around.
This is for sure the best approach. This would be a new approach,
that would be a general solution, matching various hardware (and
not only the "Valgrind hardware"). I suppose the same approach
should be done for "non remote" hardware watchpoints.

What I have added to gdb follows the current logic, i.e. mostly
"assume the best, and if it fails, tell the user so that limits can be
reduced and/or can decide to switch to software breakpoints".
I will prepare a patch with what I have done.

Philippe

Re: Why no hwatch command in gdb ?

[Daniel Jacobowitz]

On Thu, Mar 10, 2011 at 02:44:53PM +0100, Jan Kratochvil wrote:
> Hi Robert,
> 
> On Thu, 10 Mar 2011 13:18:06 +0100, robert song wrote:
> > Well, I am confused with the gdb hardware watchpoint support in x86
> > arch.
> 
> x86* is special as its debug registers capabilities are complicated - it can
> watch 1/2/4/8 bytes and there are 4 of them.  GDB supports aliasing, so if you
> watch string[0] and string[1] GDB will merge it and will watch 2 bytes at
> &string[0].

FWIW, I don't consider this unusually complicated.  MIPS, Power, and
other architectures all have hardware watchpoint features that you
can't express to GDB at all.  I do consider GDB's automatic combining
of watchpoints to be unusually complicated.

On Fri, Mar 11, 2011 at 08:58:11AM +0100, Philippe Waroquiers wrote:
> >Why can't this be negotiated between gdb and the remote?
> >Then the in-valgrind gdbserver could just report unlimited and the user
> >wouldn't have to fool around.
> This is for sure the best approach. This would be a new approach,
> that would be a general solution, matching various hardware (and
> not only the "Valgrind hardware"). I suppose the same approach
> should be done for "non remote" hardware watchpoints.

I am strongly of the opinion that we should support advanced
watchpoint capabilities.  But the details of what can be watched on a
given target are complicated.  Either we need a way to tell GDB what
the requirements are, flexibly, or we need to ask the target to
validate requests.

Every architecture has unique watchpoint features.  For instance, on
MIPS you can watch an address mask, and you can choose to match a
specific ASID or globally.  A good MIPS graphical debugger ought to be
able to pop up a dialog that lets you configure these settings.  But
they share resources with GDB's expression watchpoints.

It's an interesting problem :-)

-- 
Daniel Jacobowitz
Mentor Graphics