Jay,
Forgot to mention that :
1. the hardware breakpoint is triggered when it is a function.
2. the hardware breakpoint (write mode )is NOT triggered when its
global variable --- or memory address.
as an example :
bpha address dataw 4
this wont work !!!
3. the hardware breakpoint (read mode ) is triggered .
as an example :
bpha address datar 4
this will work !!!
and just be sure ,the registers are being set correctly when you set the
breakpoint ,but still the breakpoint is not called for case #2.
maybe the debug registers are lost due to context switching ?
Avi Nehori wrote:
> yes ,you are correct :)
> seems like the debug registers are being set correctly(i have checked it
> and debugged it ),but still the breakpoint does not
> break....
> i have done a special testing ,i can tell you that if you will write the
> memory address directly --- it will break.
> but if you write the memory address indirectly ---- it will not break !!!
>
>
>
> Jay Lan wrote:
>
>> Avi Nehori wrote:
>>
>>
>>> Jay,
>>> try to set an hardware breakpoint to a global variable and then modify it .
>>> the system will not drop into kdb in this case.
>>>
>>>
>> Hi Avi,
>>
>> I reprodued the problem. KDB hardware breakpoint is triggered on
>> access to a function, but not on value changes to a global variable.
>> It would be nice, isn't it? Hmmm...
>>
>> - jay
>>
>>
>>
>>> Jay Lan wrote:
>>>
>>>
>>>> Avi Nehori wrote:
>>>>
>>>>
>>>>
>>>>> Jay,
>>>>> the patch didnt work for me.
>>>>> I'm still looking for a resolution...
>>>>>
>>>>>
>>>>>
>>>> Hmmm, i just tested with Konstantin's patch on 2.6.25 and
>>>> 2.6.26-rc3, and it seemed to work for me.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> Entering kdb (current=0xf7841c80, pid 0) on processor 1 due to Keyboard
>>>>> Entry
>>>>>
>>>>>
>>>>>
>>>> [1]kdb> bpha do_sync
>>>> Forced Instruction(Register) BP #0 at 0xc017b6a4 (do_sync)
>>>> is enabled in dr0 globally
>>>> [1]kdb> go
>>>>
>>>> I set up a global hardware breakpoint at do_sync here.
>>>> Then i entered 'sync' command from a shell. The system dropped into KDB:
>>>>
>>>> Instruction(Register) breakpoint #0 at 0xc017b6a4
>>>> 0xc017b6a4 do_sync: push %ebx
>>>>
>>>> Entering kdb (0xf72a23a0, pid 5473) on processor 2 due to Debug @
>>>> 0xc017b6a4
>>>> [2]kdb>
>>>>
>>>> You are testing a 2.4.21 kernel... I do not know if KDB support i386
>>>> in 2.4.21 at all.
>>>>
>>>> Keith Owens did a tremendous job in making KDB backtrace working on
>>>> x86_64/i386 and fixed other bugs along the way, but his work did not
>>>> complete until 2.6.23. My brief effort of back porting the x86_64/i386
>>>> KDB support to sles10sp2 (2.6.16 based) and rhel5.2 (2.6.18 based)
>>>> did not work well. So, honestly, i recommand you move up to 2.6.23
>>>> or later.
>>>>
>>>> Thanks,
>>>> - jay
>>>>
>>>>
>>>>
>>>>
>>>>> Jay Lan wrote:
>>>>>
>>>>>
>>>>>
>>>>>> Hi Avi,
>>>>>>
>>>>>> Did Konstantin's patch work for you? His patch caused ia64
>>>>>> compilation to fail, but i would like to know if his patch
>>>>>> work for you on i386.
>>>>>>
>>>>>> Thanks!
>>>>>>
>>>>>> - jay
>>>>>>
>>>>>>
>>>>>> Scanned by Check Point Total Security Gateway.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> ---------------------------
>>>>> Use http://oss.sgi.com/ecartis to modify your settings or to unsubscribe.
>>>>>
>>>>>
>>>>>
>>>> Scanned by Check Point Total Security Gateway.
>>>>
>>>>
>>>>
>>>>
>>> ---------------------------
>>> Use http://oss.sgi.com/ecartis to modify your settings or to unsubscribe.
>>>
>>>
>> Scanned by Check Point Total Security Gateway.
>>
>>
>>
> ---------------------------
> Use http://oss.sgi.com/ecartis to modify your settings or to unsubscribe.
>
> Scanned by Check Point Total Security Gateway.
>
>
---------------------------
Use http://oss.sgi.com/ecartis to modify your settings or to unsubscribe.
