This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: [PATCH]: Make Linux use the new unified x86 watchpoint support


   Date: Tue, 27 Mar 2001 11:29:19 +0200 (IST)
   From: Eli Zaretskii <eliz@is.elta.co.il>

   On Tue, 27 Mar 2001, Mark Kettenis wrote:

   >    Sorry, I'm not following.  The watchpoint-related macros are defined
   >    on files which should be used only with native debugging (i386-nat.c
   >    and nm-i386.h).  On top of that, the macros only get exposed if the
   >    port defines I386_USE_GENERIC_WATCHPOINTS.  A port which doesn't want
   >    that should get rid of the watchpoints for free, by simply not
   >    defining I386_USE_GENERIC_WATCHPOINTS.
   > 
   >    Which part of the above misfires, and why?
   > 
   > It used to be possible to debug a remote i386 target with a native
   > Linux/x86 debugger.

   This sounds as The Source of All Evil, doesn't it?  Can GDB really be 
   tweaked into debugging a remote target with a native debug code?  I'm 
   surprised that it even works, unless there are some extra-special hacks 
   lying around, just for this.

AFAIK it has been possible for a long time.  As long as the ISA and
ABI match, there shouldn't be any problems.  Except that the
implementation of hardware breakpoints/watchpoints in core GDB is
really shoddy.

   >    This possibility has been discussed back in November, but the
   >    conclusion was that it's not a good idea.  I don't remember the
   >    details, but the reasons had something to do with threads and how
   >    the register cache is used in conjunction with threads.  (I can dig
   >    out the URLs of the relevant messages, if you want to read them.)
   > 
   > I suggested doing this, but several people objected to exposing the
   > debug registers in this way.  Threads have nothing to do with it

   I'm quite sure they did.  IIRC, the issue was that debug registers are 
   global, whereas normal registers are per thread.

I guess that depends on the underlying OS.  In Linux they are
per-process, which implies they are per-thread too.  On bare hardware,
they might be global.  With the current implementation of GDB's
register cache (which only caches registers for a single
process/thread) the difference shouldn't matter.  It's just that any
code that writes to these registers (or a user manipulating them)
should realize that it (they) might be changing a global property.

Mark


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]