public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Eli Zaretskii <eliz@delorie.com>
To: kettenis@wins.uva.nl
Cc: gdb@sources.redhat.com
Subject: Re: [RFC] Unified watchpoints for x86 platforms
Date: Thu, 15 Feb 2001 09:32:00 -0000	[thread overview]
Message-ID: <200102151732.MAA04871@indy.delorie.com> (raw)
In-Reply-To: <s3ilmr72a5u.fsf@debye.wins.uva.nl>

> From: Mark Kettenis <kettenis@wins.uva.nl>
> Date: 15 Feb 2001 17:17:17 +0100
> 
> In general, your proposal looks
> fine, but I think it is best to export functions similar to GDB's
> target_* functions:
> 
> int i386_remove_watchpoint (CORE_ADDR addr, int len,
> 			    enum target_hw_bp_type type);
> int i386_insert_watchpoint (CORE_ADDR addr, int len,
>                             enum target_hw_bp_type type);
> 
> int i386_insert_hw_breakpoint (CORE_ADDR addr, void *shadow);
> int i386_remove_hw_breakpoint (CORE_ADDR addr, void *shadow);

I didn't want to use those names because they are taken by
i386v-nat.c.  If we use these names, we will have to modify
i386v-nat.c, which is used by many x86 platforms.  I didn't want such
a profound effect; some platform maintainers might not want the new
interface, and will be less than happy to rewrite their code for no
good reason.

> > >   int i386_hwbp_insert (int pid, CORE_ADDR addr, int len, int kind);
>
> Is there any particular reason why you need the PID argument?

Just the existing interfaces.  DJGPP obviously doesn't use that
argument.

> > >     HW_READ	     break if the region is accessed for reading[1]
> > >     HW_WRITE	     break if the region is accessed for writing
> > >     HW_ACCESS	     break if the region is accessed for either
> > > 		     reading or writing
> > >     HW_IO_ACCESS     same as HW_ACCESS type, but for I/O read/write
> > > 		     access[2]
> > >     HW_EXECUTE       instruction execution breakpoint
> 
> Please consider using an enum instead of an int.  It looks as if GDB's
> convention is to use lower-case names for enum values.

I intended to use an enum.  I believe the upper-case names were just a
coincidence.

> > >   void HWBP_SET_ADDR (int pid, int dr_num, CORE_ADDR addr);
> > > 
> > >   This macro sets the debug register DR_NUM in the inferior to watch
> > >   the address ADDR.  DR_NUM can be in the range [0..3].
> > > 
> > >   void HWBP_SET_CONTROL (int pid, unsigned int val);
> > > 
> > >   This macro sets the DR7 debug control register in the inferior to
> > >   the value VAL.
> > > 
> > >   unsigned int HWBP_GET_STATUS (int pid);
> > > 
> > >   This macro returns the value of the DR6 debug status register from
> > >   the inferior.
> 
> Why not have simply long I386_GET_DR(int regnum) and I386_SET_DR(int
> regnum, long value) and let the system-dependent decide how to map the
> debug register number ([0..7], as used in the Intel documentation)
> into whatever is needed?

Why bother the target end to do that?  They will all do the same, and
the code I'll write knows exactly when it needs what register.

In addition, I386_GET_DR might mislead someone into thinking that it
actually gets the value of any DRi from the inferior.  That was not my
intention: I don't need to fetch any debug register except DR6.

Thanks for the feedback.

I think I will start coding this weekend, so if someone has more
input, please hurry ;-)

  reply	other threads:[~2001-02-15  9:32 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-09-07  1:55 gdb doesn't work very well with dynamic linked binaries James Cownie
2000-09-07  3:09 ` Mark Kettenis
2000-09-07  8:02   ` Eli Zaretskii
2000-09-08  8:30     ` Mark Kettenis
2001-02-10  7:34       ` [RFC] Unified watchpoints for x86 platforms Eli Zaretskii
2001-02-10 10:19         ` H . J . Lu
2001-02-10 11:28           ` Eli Zaretskii
2001-02-15  3:48         ` Eli Zaretskii
2001-02-15  8:17           ` Mark Kettenis
2001-02-15  9:32             ` Eli Zaretskii [this message]
2001-02-15 10:33               ` Mark Kettenis
2001-02-15 13:26                 ` Eli Zaretskii
2001-02-15 10:41             ` Kevin Buettner
2001-02-15 13:26               ` Eli Zaretskii
2001-02-15 14:46                 ` J.T. Conklin
2001-02-15 16:11                   ` Kevin Buettner
2001-02-15 23:29                     ` Eli Zaretskii
2001-02-24 10:14                     ` Eli Zaretskii
2001-02-27  3:28                       ` Mark Kettenis
2001-02-27 10:57                         ` Eli Zaretskii
2001-03-21 15:59                         ` [RFA] " Eli Zaretskii
2001-02-15 23:30                   ` [RFC] " Eli Zaretskii
2001-02-16 10:52                     ` J.T. Conklin
2001-02-16  0:00                   ` Mark Kettenis
2001-02-15  9:08           ` H . J . Lu
2000-09-09 14:39   ` gdb doesn't work very well with dynamic linked binaries Peter.Schauer
  -- strict thread matches above, loose matches on Subject: below --
2000-06-02  8:40 Proposal: convert function definitions to prototyped form David Taylor
2000-06-02 12:10 ` Kevin Buettner
2000-06-03  3:58   ` Eli Zaretskii
     [not found]     ` <eliz@delorie.com>
2000-06-03 10:50       ` Kevin Buettner
2000-06-03 11:37         ` Eli Zaretskii
2000-06-03 18:18         ` Andrew Cagney
2000-06-03 15:42       ` Kevin Buettner
2001-02-16  0:45       ` [RFC] Unified watchpoints for x86 platforms Kevin Buettner

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=200102151732.MAA04871@indy.delorie.com \
    --to=eliz@delorie.com \
    --cc=gdb@sources.redhat.com \
    --cc=kettenis@wins.uva.nl \
    /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).