What dosbox version? Tried core=normal?

Sry, forgot to mention I use v. 0.70 (win32).
Tried core=normal -> no difference.

int3 is fine, guess it uses trapping using context switches.
You can compile dosbox so it provides its own debugger btw.

*sigh* Thanks.
Just gave up compiling dosbox with debugger support.
Somehow this pdcurses doesn't compile in that MinGW/MSYS stuff (missing required file sys/ipc.h) and that crap also refuses to see the shiny lib I compiled with watcom. 😵
Any suggestions?

Erm depends on your host OS, for windows see the development forum
(think it's 0.65 only there unless Qbix already updated it), think ykhwong
has debugger-enabled builds (cvs builds thread).
What application do you want to debug? Pmode/dpmi? I'll try to look at
sd32 some time, maybe it can be fixed.

K. I'll look in the dev forum then.

And yes: I'm debugging a DOS32/a DPMI-app with DOS32a stub etc. That's why I'm still using (or trying to use *g) this half-baked sd32a debugger.
Didn't find another working DPMI-debugger so far...

Well depends on what you need, in general you should try to get your
own compiles working with pdcurses, as then you can debug pretty
much anything with the dosbox debugger.
Still dos debuggers are useful/handy by times.

Yup, but as long as they insist on opening the RealMode stub only instead of the real PM-Program, they're not. :p
If you find out something about this problem with sd32a let me know. I planned to put some work in this old patchworks (means SD32a 😉 ) anyways...

BTW: I opened another thread in the dev-forum for the compiler issues...

Seems to be using debug-registers, they're not present in dosbox
(and unlikely will be). But didn't test yet if that's the real problem.

SD only uses hardware breakpoints (for a variety of reasons) which are not supported in DOSBox. It's possible to hack in SW breakpoint support (INT 3 injection into code segment). Look at "_break_pnt" and "restore_state" fns in sdebug.asm . Remeber that the exception stackframe's format was changed sometime after DOS/32A v7.1 without SD being updated. In other words, using the latest dos32a.exe with the existing sd.exe (probably) won't work correctly unless the frame format is updated in SD sources.

Yes i noticed you removed SD from the later releases, is this just temporary
or is there a reason why it's completely removed?

Well, I suppose the main reason is because I'm lazy hehe 😉 . SD has limited application today since it is heavily bound to DOS/32A's internal API not supported by other DPMI hosts, obviously. So it doesn't work with Windows, DOS/4GW, Causeway etc. Those who still run native DOS are mostly in embedded sector, and they mostly use a Lauterbach or another HW debugger anyways. That said, if someone desperately needed to hack something useful out of SD I could probably give a few pointers.