Bug 10465 - i386 debug status register not updated as viewed using ptrace
i386 debug status register not updated as viewed using ptrace
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: glibc (Show other bugs)
6.0
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Jakub Jelinek
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-03-30 18:33 EST by pete
Modified: 2007-04-18 12:26 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-10-03 05:03:40 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
This program will illustrate the bug if executed on RH6.x (17.01 KB, text/plain)
2000-03-30 19:01 EST, pete
no flags Details
Sorry about that. ( " ) (17.01 KB, application/octet-stream)
2000-03-30 19:03 EST, pete
no flags Details
OK, here is the source then. (2.46 KB, text/plain)
2000-03-30 19:07 EST, pete
no flags Details
The main program. (10.97 KB, patch)
2000-03-30 19:10 EST, pete
no flags Details | Diff
hardware watchpont module. (5.96 KB, patch)
2000-03-30 19:11 EST, pete
no flags Details | Diff
hwatch.h (9.32 KB, patch)
2000-03-30 19:12 EST, pete
no flags Details | Diff
pdbg_types.h (579 bytes, patch)
2000-03-30 19:12 EST, pete
no flags Details | Diff
test case (265 bytes, patch)
2000-03-30 19:14 EST, pete
no flags Details | Diff
show how to modify main.c (2.20 KB, text/plain)
2000-03-30 19:16 EST, pete
no flags Details
RH5.x working script (19.19 KB, text/plain)
2000-03-30 19:16 EST, pete
no flags Details
RH6.x doesnt work. same code (13.87 KB, text/plain)
2000-03-30 19:17 EST, pete
no flags Details

  None (edit)
Description pete 2000-03-30 18:33:04 EST
I am using ptrace to set hardware watchpoints on
 linux86.  RH5.x, RH6.x.

 When a hardware watchpoint fires, a bit is set
 in the debug status register to flag this.  These
 registers are only available to level 0 processes,
 so you have to use the ptrace interface.

 I wrote a very simple debugger that, using ptrace,
 successfully sets any sort of hardware watchpoint/breakpoint
 and traps/faults in the coresponding situation
 under RH 5.x .  Most importantly, the debug
 status register (as viewed by ptrace) accurately
 reports which break/watch point fired.

 Under RH6.x, the hw watch/breakpoints traps as expected,
 but the status register does not report which watch/breakpoint
 fires.  The value of the status register is always zero.
 I am using the same code.

 Since the debug registers are not available at user level,
 and since this is a loss of information (I can't think
 of a workaround), I gave this high severity.

 Cheers,

 Pete.

  PS.  I would be *very happy* to send code.  The test debugger is
        very very simple.  I wrote it to learn by.  Underlying
	  this question is a full production debugger however.
Comment 1 pete 2000-03-30 19:01:59 EST
Created attachment 166 [details]
This program will illustrate the bug if executed on RH6.x
Comment 2 pete 2000-03-30 19:03:59 EST
Created attachment 167 [details]
Sorry about that. ( " )
Comment 3 pete 2000-03-30 19:07:59 EST
Created attachment 168 [details]
OK, here is the source then.
Comment 4 pete 2000-03-30 19:10:59 EST
Created attachment 169 [details]
The main program.
Comment 5 pete 2000-03-30 19:11:59 EST
Created attachment 170 [details]
hardware watchpont module.
Comment 6 pete 2000-03-30 19:12:59 EST
Created attachment 171 [details]
hwatch.h
Comment 7 pete 2000-03-30 19:14:59 EST
Created attachment 173 [details]
test case
Comment 8 pete 2000-03-30 19:16:59 EST
Created attachment 174 [details]
show how to modify main.c
Comment 9 pete 2000-03-30 19:17:59 EST
Created attachment 176 [details]
RH6.x doesnt work. same code
Comment 10 Cristian Gafton 2000-05-22 10:53:59 EDT
assign to jakub
Comment 11 Ulrich Drepper 2003-04-21 20:03:56 EDT
ptrace is a simple wrapper around the syscalls.  The data is passed to the
caller exactly the way the kernel provides them.  If anything is at fault it's
the kernel.

Can you reproduce the problem with RHL9?  If yes, can you attach an updated test
program?
Comment 12 Ulrich Drepper 2003-10-03 05:03:40 EDT
No reply in almost 6 months.  Reopen in case there is a problem.

Note You need to log in before you can comment on or make changes to this bug.