x86 hardware breakpoint question

x86 hardware breakpoint question

[Steven Bauer]

Quick question, does gdb support hardware breakpoints on
x86 architectures?  I have been trying to get them to work keep
getting an unknown error. 

(gdb) hbreak   *0x80485d9    

....

warning: Cannot insert breakpoint 3:
Error accessing memory address 0x80485d9: Unknown error 4294967295.


One other question, is there any way to have breakpoints enabled
when an exec occurs.  What I would like to do is continue through the
exec getting the sigtrap if the new process is loaded, delete old
breakpoints, load the symbols for the new process, and eventually 
reset breakpoints once main is hit.  The reason I want this is that
the exec could fail, in which case I want the original breakpoints to
still be in place.  If I remove all the breakpoints before the 
exec, continue, and the exec fails, I miss all the functions I 
originally had breakpoints set for.

Thanks,
Steve


 

Re: x86 hardware breakpoint question

[Eli Zaretskii]

> Date: Thu, 15 Nov 2001 12:59:27 -0500
> From: Steven Bauer <bauer@atlas.lcs.mit.edu>
> 
> Quick question, does gdb support hardware breakpoints on
> x86 architectures?

Current GDB snapshots and the pretest of GDB 5.1 should support
them.  What version do you use and on what platform?

> I have been trying to get them to work keep
> getting an unknown error. 
> 
> (gdb) hbreak   *0x80485d9    
> 
> ....
> 
> warning: Cannot insert breakpoint 3:
> Error accessing memory address 0x80485d9: Unknown error 4294967295.

What is at the address *0x80485d9?

(The unknown error simply says that the error code is -1, which means
GDB couldn't insert the breakpoint.)

Re: x86 hardware breakpoint question

[Quality Quorum]

On Thu, 15 Nov 2001, Steven Bauer wrote:

> Quick question, does gdb support hardware breakpoints on
> x86 architectures?  I have been trying to get them to work keep
> getting an unknown error.
>
> (gdb) hbreak   *0x80485d9
>
> ....
>
> warning: Cannot insert breakpoint 3:
> Error accessing memory address 0x80485d9: Unknown error 4294967295.
>
>
> One other question, is there any way to have breakpoints enabled
> when an exec occurs.  What I would like to do is continue through the
> exec getting the sigtrap if the new process is loaded, delete old
> breakpoints, load the symbols for the new process, and eventually
> reset breakpoints once main is hit.  The reason I want this is that
> the exec could fail, in which case I want the original breakpoints to
> still be in place.  If I remove all the breakpoints before the
> exec, continue, and the exec fails, I miss all the functions I
> originally had breakpoints set for.

First, it has to be supported be stub, current stub does not do it.
Plus, there are few things to be improved on the gdb side.


>
> Thanks,
> Steve
>
>
>
>

Thanks,

Aleksey

Re: x86 hardware breakpoint question

[Pierre Muller]

At 20:26 15/11/2001 , Eli Zaretskii a écrit:
> > Date: Thu, 15 Nov 2001 12:59:27 -0500
> > From: Steven Bauer <bauer@atlas.lcs.mit.edu>
> >
> > Quick question, does gdb support hardware breakpoints on
> > x86 architectures?
>
>Current GDB snapshots and the pretest of GDB 5.1 should support
>them.  What version do you use and on what platform?
But this depends on the TARGET OS:

   cygwin that completely relies on win32 API calls does not support
hardware breakpoint (nor watchpoints)
because there is no API call to set a hardware trap.



Pierre Muller
Institut Charles Sadron
6,rue Boussingault
F 67083 STRASBOURG CEDEX (France)
mailto:muller@ics.u-strasbg.fr
Phone : (33)-3-88-41-40-07  Fax : (33)-3-88-41-40-99

Re: x86 hardware breakpoint question

[Eli Zaretskii]

> Date: Fri, 16 Nov 2001 14:07:07 +0100
> From: Pierre Muller <muller@cerbere.u-strasbg.fr>
> Cc: gdb@sourceware.cygnus.com
> 
> At 20:26 15/11/2001 , Eli Zaretskii a \x7fcrit:
> > > Date: Thu, 15 Nov 2001 12:59:27 -0500
> > > From: Steven Bauer <bauer@atlas.lcs.mit.edu>
> > >
> > > Quick question, does gdb support hardware breakpoints on
> > > x86 architectures?
> >
> >Current GDB snapshots and the pretest of GDB 5.1 should support
> >them.  What version do you use and on what platform?
> But this depends on the TARGET OS:

Well, I did ask about the platform ;-)

>    cygwin that completely relies on win32 API calls does not support
> hardware breakpoint (nor watchpoints)
> because there is no API call to set a hardware trap.

I think this is just because no one implemented Cygwin support for the
new facilities on i386-nat.c.  When this was discussed a few months
ago, someone, I think DJ Delorie, posted a list of Win32 API entries
that support hardware watchpoints and breakpoints.

Re: x86 hardware breakpoint question

[Christopher Faylor]

On Fri, Nov 16, 2001 at 06:47:52PM +0200, Eli Zaretskii wrote:
>>    cygwin that completely relies on win32 API calls does not support
>> hardware breakpoint (nor watchpoints)
>> because there is no API call to set a hardware trap.
>
>I think this is just because no one implemented Cygwin support for the
>new facilities on i386-nat.c.  When this was discussed a few months
>ago, someone, I think DJ Delorie, posted a list of Win32 API entries
>that support hardware watchpoints and breakpoints.

I can't find this, Eli.  Can you provide any clues on what to look for?
I'd like to have hardware brekpoints into cygwin if I can.

cgf

Re: x86 hardware breakpoint question

[muller]

At 15:54 16/11/01 -0500, Christopher Faylor wrote:
>On Fri, Nov 16, 2001 at 06:47:52PM +0200, Eli Zaretskii wrote:
>>>    cygwin that completely relies on win32 API calls does not support
>>> hardware breakpoint (nor watchpoints)
>>> because there is no API call to set a hardware trap.
>>
>>I think this is just because no one implemented Cygwin support for the
>>new facilities on i386-nat.c.  When this was discussed a few months
>>ago, someone, I think DJ Delorie, posted a list of Win32 API entries
>>that support hardware watchpoints and breakpoints.
>
>I can't find this, Eli.  Can you provide any clues on what to look for?
>I'd like to have hardware brekpoints into cygwin if I can.

I had pseudo-hardware watchpoints working using the page protection
mechanisms available with the VirtualXXX functions.

 I am trying to get up to date my old code that added
"hardware" watchpoints with VirtualProtectEx.
As soon as this works correctly again, I will send 
a patch, even if my code is far from optimal,
because otherwise it will again get lost in 
confilcts with future changes...

Re: x86 hardware breakpoint question

[DJ Delorie]

> I can't find this, Eli.  Can you provide any clues on what to look for?
> I'd like to have hardware brekpoints into cygwin if I can.

SetThreadContext can set the hardware debug registers.

Re: x86 hardware breakpoint question

[muller]

At 17:32 16/11/01 -0500, DJ Delorie wrote:
>
>> I can't find this, Eli.  Can you provide any clues on what to look for?
>> I'd like to have hardware brekpoints into cygwin if I can.
>
>SetThreadContext can set the hardware debug registers.
Did you try this out already ?

  Because one of the problems that I got with my code
that uses VirtualProtectEx is that I can't change the
single step bit inside a system DLL (under win95 at least).

This forced me to add some complicated code,
that goes up the frame and sets a breakpoint at the first not
system DLL return address.

 Outside system DLL I can single step over an
instruction that triggered the page protection
(momentantly disabling that protection) if
the address triggering the page protection is
not a watched address.

  So I am surprised to hear that win32
lets you set debug registers, but if that works, great!

 Are the debug registers process wide or
thread specific in that case ?

Re: x86 hardware breakpoint question

[DJ Delorie]

>   So I am surprised to hear that win32
> lets you set debug registers, but if that works, great!

I don't know if it works, I just looked it up in the documentation.

>  Are the debug registers process wide or
> thread specific in that case ?

Well, it is Set*Thread*Context.

Re: x86 hardware breakpoint question

[Christopher Faylor]

On Fri, Nov 16, 2001 at 05:57:04PM -0500, DJ Delorie wrote:
>
>>   So I am surprised to hear that win32
>> lets you set debug registers, but if that works, great!
>
>I don't know if it works, I just looked it up in the documentation.
>
>>  Are the debug registers process wide or
>> thread specific in that case ?
>
>Well, it is Set*Thread*Context.

Which is, conveniently enough, what gdb is already using.  :-)

Did you find specific documentation on the hardware registers, though?

I see this in the system header:

    BYTE    ExtendedRegisters[MAXIMUM_SUPPORTED_EXTENSION];

but I don't see any description about how to use them.

cgf

Re: x86 hardware breakpoint question

[muller]

At 20:10 16/11/01 -0500, Christopher Faylor wrote:
>On Fri, Nov 16, 2001 at 05:57:04PM -0500, DJ Delorie wrote:
>>
>>>   So I am surprised to hear that win32
>>> lets you set debug registers, but if that works, great!
>>
>>I don't know if it works, I just looked it up in the documentation.
>>
>>>  Are the debug registers process wide or
>>> thread specific in that case ?
>>
>>Well, it is Set*Thread*Context.
>
>Which is, conveniently enough, what gdb is already using.  :-)
>
>Did you find specific documentation on the hardware registers, though?
>
>I see this in the system header:
>
>    BYTE    ExtendedRegisters[MAXIMUM_SUPPORTED_EXTENSION];
>
>but I don't see any description about how to use them.

  No, these are for xmme registers of Pentium III
or possibly other registers of other kind of i386 compatible regs.

  The debug registers are DR0-3 DR6 and DR7.

DR0 to 3 are the four linear addresses watchpoints
and DR6 and DR7 are used for indicating type and size of
the different breakpoints.

  I think that DJ expects that we can directly write
the values of the DR registers using  SetThreadContext.
This needs to be tested.

ContextFlags field of context structure must contain
CONTEXT_DEBUG_REGISTERS which isn't yet included into 
CONTEXT_DEBUG used in win32-nat code.