On 12/16/15 20:03, Richard Henderson wrote:
On 12/15/2015 01:02 PM, Sergey Fedorov wrote:
For that, I think it might be interesting to arrange for non-empty
TBs to
exit prior to recognizing a breakpoint. So that a breakpoint TB is
always
just the one operation. Except for the fact that
On 12/15/2015 01:02 PM, Sergey Fedorov wrote:
For that, I think it might be interesting to arrange for non-empty TBs to
exit prior to recognizing a breakpoint. So that a breakpoint TB is always
just the one operation. Except for the fact that "generate an exception" has
traditionally been a
On 12/14/15 19:19, Richard Henderson wrote:
On 12/12/2015 12:02 PM, Sergey Fedorov wrote:
On 12/12/15 02:39, Richard Henderson wrote:
On 12/10/2015 10:47 AM, Sergey Fedorov wrote:
The "PC advancement" trick was used just after recognizing that a
breakpoint exception was going to be generated.
On 12/12/2015 12:02 PM, Sergey Fedorov wrote:
On 12/12/15 02:39, Richard Henderson wrote:
On 12/10/2015 10:47 AM, Sergey Fedorov wrote:
The "PC advancement" trick was used just after recognizing that a
breakpoint exception was going to be generated. This trick has had two
points:
1.
On 12/12/15 02:39, Richard Henderson wrote:
On 12/10/2015 10:47 AM, Sergey Fedorov wrote:
The "PC advancement" trick was used just after recognizing that a
breakpoint exception was going to be generated. This trick has had two
points:
1. Guarantee that tb->size isn't zero: there are many
On 12/10/2015 10:47 AM, Sergey Fedorov wrote:
The "PC advancement" trick was used just after recognizing that a
breakpoint exception was going to be generated. This trick has had two
points:
1. Guarantee that tb->size isn't zero: there are many places where it's
expected to be non-zero.
The "PC advancement" trick was used just after recognizing that a
breakpoint exception was going to be generated. This trick has had two
points:
1. Guarantee that tb->size isn't zero: there are many places where it's
expected to be non-zero. In fact, that is even stated in the comment
