From: Eli Zaretskii <eliz@delorie.com>
To: hjl@valinux.com
Cc: gdb-patches@sourceware.cygnus.com, gdb@sourceware.cygnus.com
Subject: Re: A patch for ia32 hardware watchpoint.
Date: Sat, 01 Apr 2000 00:00:00 -0000 [thread overview]
Message-ID: <200003081012.FAA16486@indy.delorie.com> (raw)
Message-ID: <20000401000000.dWdgGlhF1-SuHJh1RzzoBWy4QGEx7H8kX9WFow-kJjA@z> (raw)
In-Reply-To: <20000307132613.B20282@valinux.com>
> This is a patch for
>
> http://sourceware.cygnus.com/ml/gdb/2000-q1/msg00564.html
I have problems with this patch. See below.
> I only did it for Linux since it is not a perfect solution.
No, you also changed nm-go32.h, which is not related to Linux (AFAIK),
and changed the global definition of two macros on breakpoint.c.
> +#ifdef NEED_WATCHPOINT_NUMBER
> + val = target_insert_watchpoint (b->number, addr,
> + len, type);
> +#else
Please explain why is this needed. The DJGPP version works well
without knowing the breakpoint number, but if there's a good reason
for passing b->number, it should be done on all x86 platforms. So
let's discuss this.
> + /* Don't return an error if we fail to insert
> + a hardware watchpoint due to the limited number
> + of hardware watchpoints availabel. */
> + val = (errno == EBUSY) ? 0 : -1;
> + }
Why is this a good idea? The result of this is that GDB will not know
that it cannot insert a watchpoint until it actually resumes the
debuggee, which is too late in many cases; and the user gets confusing
error messages. x86 doesn't have a good way of checking whether the
debug registers are enough to cover the requests, but whenever it
does, why not use it?
> @@ -5500,13 +5513,13 @@ watch_command_1 (arg, accessflag, from_t
> in hardware return zero. */
>
> #if !defined(TARGET_REGION_SIZE_OK_FOR_HW_WATCHPOINT)
> -#define TARGET_REGION_SIZE_OK_FOR_HW_WATCHPOINT(BYTE_SIZE) \
> - ((BYTE_SIZE) <= (REGISTER_SIZE))
> +#define TARGET_REGION_SIZE_OK_FOR_HW_WATCHPOINT(VAL) \
> + (TYPE_LENGTH (VALUE_TYPE (VAL)) <= (REGISTER_SIZE))
> #endif
>
> #if !defined(TARGET_REGION_OK_FOR_HW_WATCHPOINT)
> -#define TARGET_REGION_OK_FOR_HW_WATCHPOINT(ADDR,LEN) \
> - TARGET_REGION_SIZE_OK_FOR_HW_WATCHPOINT(LEN)
> +#define TARGET_REGION_OK_FOR_HW_WATCHPOINT(VAL) \
> + TARGET_REGION_SIZE_OK_FOR_HW_WATCHPOINT(VAL)
> #endif
These are IMHO wrong: the number of debug registers required for a
particular region is a function of the address, not only size (e.g., a
single x86 debug register cannot watch a 32-bit region that isn't
aligned on 4-byte boundary). If Linux, for some reason, doesn't need
the address (although I cannot see how could this be right, at least
for native debugging), please define a platform-specific macro instead
of overwriting system-wide defaults.
The DJGPP version actually *uses* the ADDR part of the above
definition, since it knows how to cover a region with several
watchpoints.
> --- config/i386/nm-go32.h 2000/03/07 18:42:21 1.1.1.2
> +++ config/i386/nm-go32.h 2000/03/07 18:53:48
> @@ -44,10 +44,10 @@
> #define TARGET_CAN_USE_HARDWARE_WATCHPOINT(type, cnt, ot) 1
>
> /* Returns non-zero if we can use hardware watchpoints to watch a region
> - whose address is ADDR and whose length is LEN. */
> + which represents VAL. */
>
> -#define TARGET_REGION_OK_FOR_HW_WATCHPOINT(addr,len) \
> - go32_region_ok_for_watchpoint(addr,len)
> +#define TARGET_REGION_OK_FOR_HW_WATCHPOINT(val) \
> + go32_region_ok_for_watchpoint((VALUE_ADDRESS (val) + VALUE_OFFSET (val)),TYPE_LENGTH (VALUE_TYPE (val)))
Please do not commit this one, it disables a valuable feature in the
DJGPP version.
next prev parent reply other threads:[~2000-04-01 0:00 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-03-07 13:33 H . J . Lu
2000-03-07 21:52 ` J.T. Conklin
2000-03-08 0:46 ` Todd Whitesel
2000-03-08 6:04 ` Jim Kingdon
2000-03-08 19:44 ` Todd Whitesel
2000-04-01 0:00 ` Todd Whitesel
2000-03-09 7:06 ` Andrew Cagney
2000-04-01 0:00 ` Andrew Cagney
2000-04-01 0:00 ` Jim Kingdon
2000-03-09 5:28 ` Eli Zaretskii
2000-04-01 0:00 ` Eli Zaretskii
2000-03-09 11:28 ` breakpoint insert API (was: A patch for ia32 hardware watchpoint.) J.T. Conklin
2000-03-09 15:15 ` Jim Kingdon
2000-04-01 0:00 ` Jim Kingdon
2000-03-09 15:33 ` Andrew Cagney
2000-03-09 17:28 ` Todd Whitesel
2000-03-14 15:15 ` J.T. Conklin
2000-03-14 15:31 ` Todd Whitesel
2000-04-01 0:00 ` Todd Whitesel
2000-04-01 0:00 ` J.T. Conklin
2000-04-01 0:00 ` Todd Whitesel
2000-03-14 14:10 ` J.T. Conklin
2000-03-21 2:50 ` Andrew Cagney
2000-04-01 0:00 ` Andrew Cagney
2000-04-01 0:00 ` J.T. Conklin
2000-04-01 0:00 ` Andrew Cagney
2000-03-09 17:33 ` Todd Whitesel
2000-03-14 14:56 ` J.T. Conklin
2000-03-21 3:11 ` Andrew Cagney
2000-03-21 6:10 ` Richard Earnshaw
2000-04-01 0:00 ` Richard Earnshaw
2000-04-01 0:00 ` Andrew Cagney
2000-04-01 0:00 ` J.T. Conklin
2000-04-01 0:00 ` Todd Whitesel
2000-04-01 0:00 ` J.T. Conklin
2000-04-01 0:00 ` A patch for ia32 hardware watchpoint Todd Whitesel
2000-04-01 0:00 ` J.T. Conklin
2000-03-08 2:14 ` Eli Zaretskii [this message]
2000-04-01 0:00 ` Eli Zaretskii
2000-03-08 3:32 ` Eli Zaretskii
2000-04-01 0:00 ` Eli Zaretskii
2000-04-01 0:00 ` H . J . Lu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200003081012.FAA16486@indy.delorie.com \
--to=eliz@delorie.com \
--cc=gdb-patches@sourceware.cygnus.com \
--cc=gdb@sourceware.cygnus.com \
--cc=hjl@valinux.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).