This is the mail archive of the gdb@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: About unified debug register handling for i386 CPU.


> Date: Wed, 06 Sep 2000 00:13:39 +0200
> From: Pierre Muller <pierre@idefix.wisa.be>
> 
>   Just a short comment to remind everyone that 
> at least in DPMI you don't have direct access to the debug register.

Yes, there's a system call to set and reset them.

>   (Imagine for instance that you debug gdb with itself
> and place a hardware watchpoint on the top-gdb,
> only 3 hardware debug registers are available to
> the second gdb, but you will only notice that by a failure
> to set the fourth hardware register !)

This is a known problem with the DJGPP port.  It is one of a list of
problems that need special care because the debugger and the debuggee
are really one process.

In this case, I think the DJGPP debug support library functions should
allow to query about the number of free debug registers.  It is
somewhere on my TODO.

>   Thus handling them as normal registers,
> by changing individual values, can 
> lead to unconsitant states that can not be really passed
> to the DPMI provider.

If the access to debug registers is only through a well-defined API
(i.e., functions), then we can take care of this problem.

>   Moreover, I don't think that most people will care about 
> having debug registers listed on 'info all' command.
> Maybe 'info debug-register' would be a better solution here.

I'm not sure.  Most people don't care about FP registers, either, but
"info all" does print them.  We have "info registers" for those who
only want to see the ``normal'' registers.  IMHO, too many different
commands with overlapping functionality is not a Good Thing.

>   Remember also that the win32 API does not support 
> hardware debug registers

Really?  So you cannot have hardware-assisted debugging in Win32
applications?

> so adding them to the cygwin target would be very wrong

This could be solved in the same way as x86 targets which don't
support FP registers.

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