Bug 10465 - i386 debug status register not updated as viewed using ptrace
Summary: i386 debug status register not updated as viewed using ptrace
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: glibc   
(Show other bugs)
Version: 6.0
Hardware: i386
OS: Linux
medium
high
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact:
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2000-03-30 23:33 UTC by pete
Modified: 2016-11-24 15:00 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-10-03 09:03:40 UTC
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-31 00:01 UTC, pete
no flags Details
Sorry about that. ( " ) (17.01 KB, application/octet-stream)
2000-03-31 00:03 UTC, pete
no flags Details
OK, here is the source then. (2.46 KB, text/plain)
2000-03-31 00:07 UTC, pete
no flags Details
The main program. (10.97 KB, patch)
2000-03-31 00:10 UTC, pete
no flags Details | Diff
hardware watchpont module. (5.96 KB, patch)
2000-03-31 00:11 UTC, pete
no flags Details | Diff
hwatch.h (9.32 KB, patch)
2000-03-31 00:12 UTC, pete
no flags Details | Diff
pdbg_types.h (579 bytes, patch)
2000-03-31 00:12 UTC, pete
no flags Details | Diff
test case (265 bytes, patch)
2000-03-31 00:14 UTC, pete
no flags Details | Diff
show how to modify main.c (2.20 KB, text/plain)
2000-03-31 00:16 UTC, pete
no flags Details
RH5.x working script (19.19 KB, text/plain)
2000-03-31 00:16 UTC, pete
no flags Details
RH6.x doesnt work. same code (13.87 KB, text/plain)
2000-03-31 00:17 UTC, pete
no flags Details

Description pete 2000-03-30 23:33:04 UTC
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-31 00:01:59 UTC
Created attachment 166 [details]
This program will illustrate the bug if executed on RH6.x

Comment 2 pete 2000-03-31 00:03:59 UTC
Created attachment 167 [details]
Sorry about that. ( " )

Comment 3 pete 2000-03-31 00:07:59 UTC
Created attachment 168 [details]
OK, here is the source then.

Comment 4 pete 2000-03-31 00:10:59 UTC
Created attachment 169 [details]
The main program.

Comment 5 pete 2000-03-31 00:11:59 UTC
Created attachment 170 [details]
hardware watchpont module.

Comment 6 pete 2000-03-31 00:12:59 UTC
Created attachment 171 [details]
hwatch.h

Comment 7 pete 2000-03-31 00:14:59 UTC
Created attachment 173 [details]
test case

Comment 8 pete 2000-03-31 00:16:59 UTC
Created attachment 174 [details]
show how to modify main.c

Comment 9 pete 2000-03-31 00:17:59 UTC
Created attachment 176 [details]
RH6.x doesnt work. same code

Comment 10 Cristian Gafton 2000-05-22 14:53:59 UTC
assign to jakub

Comment 11 Ulrich Drepper 2003-04-22 00:03:56 UTC
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 09:03:40 UTC
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.