Implementing hardware breakpoints using x86 debug register

[RajivKumarSrivastav]

I am writing program to implement hardware breakpoints using x86 Debug Registers, it’s not working somehow .
X86 Interrupt descriptor table (IDT) for exceptions and GDT for segments are set properly. I am not using paging and it’s in Protected mode when I set DR registers.

Per Intel manual (System Programming Guide 1– Chapter- 16) , if I set DR0 to DR3 with 4 addresses and enable them using DR6 , then HW breakpoint should work. I referred LINUX source (version 2.6.37.3) for files Hw_breakpoint.c which also does same thing.
I tried ACCESS and EXECUTE breakpoint one by one but none is working. Below is the given source which writes into Debug Registers.

Code: Select all

// These address reference to valid function address in my source code.
void Setx86DebugReg(void)
{
         unsigned int dr0=0xfffe0b9e, dr1=0xfffe02dc,  dr2=0xfffe0300,  dr3 =0xfffe053c;
         unsigned int dr7=0x000007ff; // or 0x4aa or 0x7aa or 0x6aa -> also not working

        asm volatile ("movl %%eax, %%dr0":: "a"(dr0));
        asm volatile ("movl %%eax, %%dr1":: "a"(dr1));
        asm volatile ("movl %%eax, %%dr2":: "a"(dr2));
        asm volatile ("movl %%eax, %%dr3":: "a"(dr3)); 
        asm volatile ("movl %%eax, %%dr7":: "a"(dr7));
 return;
}

Please help and let me know if i need to set any other Register too. Or if i am missing something ?
After call to Setx86DebugReg() function, i should be able to hit breakpoint, which is not happening.

[Owen]

Real hardware or emulator? In the later case... emulators are notorious for not implementing the debugging hardware.

For instruction breakpoints, you're often best off substituting the first byte of the instruction for an INT3 opcode (and recording somewhere the the original byte so it can be restored and the instruction single stepped)

[RajivKumarSrivastav]

Thanks for the reply. I am working with real x486 hardware.

[Combuster]

[edit] I misinterpreted the documentation [/edit]

[RajivKumarSrivastav]

Intel manual "system programming guide 1" .
CHAPTER 16 - DEBUGGING, PROFILING BRANCHES AND TIMESTAMP COUNTER.
First Para:

Intel 64 and IA-32 architectures provide debug facilities for use in debugging code
and monitoring performance. These facilities are valuable for debugging application
software, system software, and multitasking operating systems. Debug support is
accessed using debug registers (DB0 through DB7) and model-specific registers (MSRs):

Does it mean 486 lacks DRx ( 0r DBx) registers ?

[iansjack]

The 486 lacked DRx registers...

I believe that information is incorrect. http://bitsavers.org/pdf/intel/_dataShe ... _Apr89.pdf

[Combuster]

I should read properly. The debugging extensions were added after the 486, and its summarisation across several documents led me to the conclusion that without that capability the developer was left with Trapflag and 0xCC debugging.

At any rate, the OP should at least check whether he is trying to use the definition of 386 watchpoints or P1 watchpoints when the CPU is left in the other state.

[RajivKumarSrivastav]

Thanks. But my question still remains and given code does not work.
Please let me know, if i am missing something. I have already tried with all possible option through DR7 - control register.

[stlw]

I would suggest you an opposite of others. Did you try to compile Bochs with --enable-x86-debugger and try the same ?

Bochs x86 debugger handling is pretty good, it has issues with reporting non-enabled breakpoints to DR6 (x86 gray area) but in the mainstream stuff it should work like HW.

Stanislav

[RajivKumarSrivastav]

I am not using Bochs. I am using x86 hardware.

[stlw]

I am not using Bochs. I am using x86 hardware.

The code breakpoint could be missed if breakpoint trap cannot be executed for some reason.

For example debug trap is blocked by MOV_SS instruction.

Or for example code breakpoint won't be checked when EFLAGS.RF flag is set.

Stanislav

[RajivKumarSrivastav]

Thanks all for reply.
My code and concept was correct, but somehow tool to work with x86 hw had problem. Problem was solved When i switched to another tool.