Bug 467021 - hardware breakpoint not planted after hardware breakpoint limit is reached
Summary: hardware breakpoint not planted after hardware breakpoint limit is reached
Status: RESOLVED FIXED
Alias: None
Product: TCF
Classification: Tools
Component: Agent (show other bugs)
Version: unspecified   Edit
Hardware: PC Linux
: P3 normal (vote)
Target Milestone: 1.3   Edit
Assignee: Project Inbox CLA
QA Contact: Eugene Tarassov CLA
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-05-11 12:38 EDT by Eric Le Port CLA
Modified: 2015-06-16 03:17 EDT (History)
0 users

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Eric Le Port CLA 2015-05-11 12:38:23 EDT 
- Try to put 5 hardware breakpoints
- 5th one can not be planted because there is not enough resource
- remove one, the 5th one is still not planted (even if resource is now available)
- disable/enable it. It is now planted.
Comment 1 Eugene Tarassov CLA 2015-05-12 17:33:50 EDT 
Fixed.
Thanks!
Comment 2 Eric Le Port CLA 2015-05-13 11:55:38 EDT 
(In reply to Eugene Tarassov from comment #1)
> Fixed.
> Thanks!

Can you explain why you need to test whether bi->cb.ctx is stopped to add the  breakpoint in the list?
Comment 3 Eugene Tarassov CLA 2015-05-13 14:31:31 EDT 
(In reply to Eric Le Port from comment #2)
> (In reply to Eugene Tarassov from comment #1)
> > Fixed.
> > Thanks!
> 
> Can you explain why you need to test whether bi->cb.ctx is stopped to add
> the  breakpoint in the list?

We have to check current running/stopped state, because, normally, planting breakpoint while context is running is not supported, and it will fail. In particular, we should not select a context, which would fail assertions in plant_instruction(). However, you are right, checking bi->cb.ctx->stopped is not correct - it works only when "breakpoints group" is same as "stop group". The right check is is_all_stopped(bi->cb.ctx). Fixed.