🚀 go-pugleaf

I now suspect/speculate (no verification attempted) its because I actually 
had two address breakpoints set - It set up for one, and stored/saved actual 
data - it set up for the second one, and stored/saved the replaced byte from 
the previous one, an int 3 - So I can also speculate that it sets up for 
breakpoints traversing the list in one direction, and "undoes" the 
breakpoints in the same direction - whereas it might have "undone" them in 
the reverse order of setting them, and actually gotten the original data 
back in place.  (In which case I'd still have no clue what was going on.)

This still does not explain how the display shows what should be there, 
rather than what is apparently actually there.  Maybe the display is 
retrieving data via one thread, while the breakpoint management is done via 
another thread, and the display just happens to fetch data after 'first' 
breakpoint (with correct data) is restored, but before 'second' breakpoint 
with incorrect data is 'restored' (overwriting actual data.)

(CGMWTTN - CodeGearMayWantToTakeNotice)
This may beg the additional question of what happens if I wanted to set two 
breakpoints with two different conditions at the same address.  The debugger 
allows me to set the two breakpoints, but what will the reliability of its 
interpretation of the expressions be, if the referenced data is not correct?


"Alan Bellingham" <alan@lspace.org> wrote in message 
news:veu0849paoflcoovi6nkrjk8gtcf2ap2he@4ax.com...
> "dhoke" <dhoke.nojunk@east-shore.com> wrote:
>
>>Perhaps it treats the traps of coded int 3's differently from the
>>breakpoints it sets, in this regard (or not - but right now I don't feel
>>like trying to figure that out.)
>
> I know little about the internal operation of debuggers, but if it sets
> a breakpoint, it may be replacing the instruction that was at the
> breakpoint position with the 'int 3'. It knows that it's done so, and
> when it stops, it can replace the instruction with the original before
> single-step executing it, and returning the 'int 3' afterwards.
>
> On the other hand, an 'int 3' in your compiled code *was* the original
> instruction. So no replacement was made, and the debugger *has* to treat
> it differently. (For one, executing the *next* instruction next, rather
> than the current (replaced) one.
>
> Alan Bellingham
> -- 
> Team Browns
> ACCU Conference 2009: to be announced