suggestion for skipping unwanted int 3s

[440bx]

Hello,

One of the best recent additions to FpDebug is it honors DebugBreak(). 

Unfortunately, when running a 32 bit program under FpDebug, some versions of Windows have a built in int 3 in the loader which causes FpDebug to break there.  That break is an annoyance.

FpDebug could ignore an int 3 that occurs outside the program's code if it isn't followed by a "ret" (it is and, must be, in DebugBreak()).  Effectively that would likely eliminate all or most unwanted int 3s.  (the behavior could also be a user option.)

Just a thought.  It would be convenient not to have every 32 bit program be stopped in its tracks while loading.

[Martin_fr]

Please make it a feature request.

The location in "DebugBreak()" can probably be detected by the proximity to the name dll entry point. (though there could be a jump pad at the entry point...).

If DebugBreak is detected as special break, then it could even display the calling code, instead of the asm for the int-3.


Not sure what will be first. There is an unrelated idea, not meant for int3, but possible useful to "simulate DebugBreak".

Currently breakpoints can have
- file / line-num
- address

In future they could also have "function name" (including dll entry point name).

So then (with int3 disabled) a breakpoint could be set at DebugBreak.
Just by coincidence doing a similar thing (not meant as a replacement)

[440bx]

Please make it a feature request.

Done: #40827
Link: https://gitlab.com/freepascal.org/fpc/source/-/issues/40827

The location in "DebugBreak()" can probably be detected by the proximity to the name dll entry point. (though there could be a jump pad at the entry point...).

That's why I like the idea of checking the instruction after the int 3 because it's independent of how it got there and it's only one byte and it's already at the current IP.  It's asking for it

[Martin_fr]

But a ret instruction after an int3 can happen anywhere.

In any case, it needs to be in the correct dll (kernel/ntdl/... have to check). And that dll can change, and either check can be affected by such a check.