Problem with manual watchpoints

Problem with manual watchpoints

[Aravinda]

Hi,

Im facing a very wierd problem. Its nothing to do with GDB, but i was
just wondering if theres something about 'hardware watchpoints' im
missing here.

I have a kernel module that can add watchpoints for a process. The
module can be invoked by __add_watchpoint(pid, address).
I wrote the program below to test the module. In the below program, I
have allocated a buffer 'a' and access 'a[0], a[1] .... a[25]'. I have
the address of a[20] loaded in one of the debug register.

a = malloc(20);
__add_watchpoint(getpid(), &a[20]);

for (i = 0; i < 25; i ++) {
	/* getc(stdin); ----> without this, no SIGTRAP is getting generated */
	printf("Accessing now %x\n", &a[i]);
	a[i]++;
}

While I expect the program to be interrupted by a tracepoint exception
on accessing a[20], it actually does not. It runs to completion
without catching any trap exception. However, if I just add a
'getc(stdin)' before accessing every element, it does get the
exception on accessing a[20].

Does anyone know what could be going on ?

Thanks,
Aravinda

Re: Problem with manual watchpoints

[Jan Kratochvil]

On Thu, 24 Dec 2009 21:47:06 +0100, Aravinda wrote:
> a = malloc(20);
> __add_watchpoint(getpid(), &a[20]);
> 
> for (i = 0; i < 25; i ++) {
> 	/* getc(stdin); ----> without this, no SIGTRAP is getting generated */
> 	printf("Accessing now %x\n", &a[i]);
> 	a[i]++;
> }

What is the type of "a"?  After "a = malloc(20);" you can access elements
a[0]...a[19] but a[20] is already after the allocated array size.

Also the loop is till "i < 25" but you have allocated only 20 elements.  In
fact you may have allocated only 5 elements if "*a" is "int" etc.


> However, if I just add a 'getc(stdin)' before accessing every element, it
> does get the exception on accessing a[20].

You have data corruption in your program so it behaves very unpredictably.


Please run some valgrind or mudflap on it.  At least try it first in userland
if it should be a kernel module.


Regards,
Jan

Re: Problem with manual watchpoints

[Aravinda]

Thanks Jan,

replied inline.

On Thu, Dec 24, 2009 at 4:08 PM, Jan Kratochvil
<jan.kratochvil@redhat.com> wrote:
> On Thu, 24 Dec 2009 21:47:06 +0100, Aravinda wrote:
>> a = malloc(20);
>> __add_watchpoint(getpid(), &a[20]);
>>
>> for (i = 0; i < 25; i ++) {
>>       /* getc(stdin); ----> without this, no SIGTRAP is getting generated */
>>       printf("Accessing now %x\n", &a[i]);
>>       a[i]++;
>> }
>
> What is the type of "a"?
a is char*.
>After "a = malloc(20);" you can access elements
> a[0]...a[19] but a[20] is already after the allocated array size.
>
> Also the loop is till "i < 25" but you have allocated only 20 elements.  In
> fact you may have allocated only 5 elements if "*a" is "int" etc.
Yes, thats why I have a watchpoint added at &a[20]. So on accessing
the first element out of the allocated array, I want the program to
receive a SIGTRAP.
>
>
>> However, if I just add a 'getc(stdin)' before accessing every element, it
>> does get the exception on accessing a[20].
>
> You have data corruption in your program so it behaves very unpredictably.
But I have &a[20] in DR0 with necessary DR7 bits enabled, isnt the
program supposed to get a Trap/Breakpoint exception on accessing it
(the very first element out of the allocated buffer) ? Im trying to
avoid the memory corruption by handling SIGTRAP and aborting the
program.
Infact it gets this signal when the getc(stdin) is included, is it
something to do with the program should be in single step mode to get
SIGTRAPs or is the loop way too simple that it executes in no time
before the SIGTRAP is even raised ?

Thanks,
Aravinda

Re: Problem with manual watchpoints

[Jan Kratochvil]

On Thu, 24 Dec 2009 22:41:37 +0100, Aravinda wrote:
> Yes, thats why I have a watchpoint added at &a[20]. So on accessing
> the first element out of the allocated array, I want the program to
> receive a SIGTRAP.

Ah, OK.

> Infact it gets this signal when the getc(stdin) is included, is it
> something to do with the program should be in single step mode to get
> SIGTRAPs

No.

> or is the loop way too simple that it executes in no time before the SIGTRAP
> is even raised ?

There may be some compiler optimization in effect such as if you have not used
"volatile" keyword for the "a" array. You should rather check the code using
"objdump -dS" or GDB "disass/m" how it got compiled.

Still (with default -O0) I do not know the answer.


Regards,
Jan

Re: Problem with manual watchpoints

[Aravinda]

Hi Jan,

Thanks again for the reply. When I tried with -O0, i found that, the
same program got the breakpoint exception. But there were also times
when it just ran to completion too. I then went back to the -O2 and
ran the compiled program several times and found that, even with -O2,
the breakpoint exception occurs sometimes and does not occur at other
times.

Reading about debug registers and breakpoint exception, I came across this
"When using data breakpoints it is recommended that either the LE or
GE bit of DR7 be set also. If either LE or GE is set, any data
breakpoint trap is reported exactly after completion of the
instruction that accessed the specified memory item. This exact
reporting is accomplished by forcing the 80386 execution unit to wait
for completion of data operand transfers before beginning execution of
the next instruction. If neither GE nor LE is set, data breakpoints
may not be reported until one instruction after the data is accessed
or may not be reported at all."

Which means, Im just having some trouble with exact reporting of the
exception I guess. Inspite of having both LE and GE set, the behaviour
is random. Could it be possible for a processor with debug registers
to not support exact reporting or could there be problems since Im
working on a VM ?

Thanks,
Aravinda

On Thu, Dec 24, 2009 at 4:52 PM, Jan Kratochvil
<jan.kratochvil@redhat.com> wrote:
> On Thu, 24 Dec 2009 22:41:37 +0100, Aravinda wrote:
>> Yes, thats why I have a watchpoint added at &a[20]. So on accessing
>> the first element out of the allocated array, I want the program to
>> receive a SIGTRAP.
>
> Ah, OK.
>
>> Infact it gets this signal when the getc(stdin) is included, is it
>> something to do with the program should be in single step mode to get
>> SIGTRAPs
>
> No.
>
>> or is the loop way too simple that it executes in no time before the SIGTRAP
>> is even raised ?
>
> There may be some compiler optimization in effect such as if you have not used
> "volatile" keyword for the "a" array. You should rather check the code using
> "objdump -dS" or GDB "disass/m" how it got compiled.
>
> Still (with default -O0) I do not know the answer.
>
>
> Regards,
> Jan
>

Re: Problem with manual watchpoints

[Jan Kratochvil]

On Mon, 28 Dec 2009 22:21:34 +0100, Aravinda wrote:
> Could it be possible for a processor with debug registers to not support
> exact reporting or could there be problems since Im working on a VM ?

Which "VM"?  It is true some old KVMs had some bugs with watchpoints.  Those
are fixed long time (such as at least in kernel-2.6.31.9-174.fc12.x86_64).
You can run the gdb testsuite both in host and in guest OS and compare it.
You can also compare the results from:
	http://sourceware.org/systemtap/wiki/utrace/tests


Regards,
Jan

Re: Problem with manual watchpoints

[Aravinda]

Hi,

Thanks a lot. I tried the ptrace testsuite and found nothing was wrong
with the VM; all tests ran fine.

But, i figured the problem was, I was doing an ioctl to access the
kernel module which runs in the same process context and so, sometimes
the assigning

task_struct->thread_struct->debugreg[0] = addr

was actually not committed to the address to the hardware debug
register. I forced a move to debug register by calling
processor.h/set_debugreg(val, regno). It consistently raises the
SIGTRAP now. Looking at ptrace code in the linux, they dont have to do
it since its from a different process the DR values are modified so
when the child process is scheduled back,  the modified DR values are
copied into the hardware debug registers.

Thanks,
Aravinda

On Mon, Dec 28, 2009 at 4:48 PM, Jan Kratochvil
<jan.kratochvil@redhat.com> wrote:
> On Mon, 28 Dec 2009 22:21:34 +0100, Aravinda wrote:
>> Could it be possible for a processor with debug registers to not support
>> exact reporting or could there be problems since Im working on a VM ?
>
> Which "VM"?  It is true some old KVMs had some bugs with watchpoints.  Those
> are fixed long time (such as at least in kernel-2.6.31.9-174.fc12.x86_64).
> You can run the gdb testsuite both in host and in guest OS and compare it.
> You can also compare the results from:
>        http://sourceware.org/systemtap/wiki/utrace/tests
>
>
> Regards,
> Jan
>