so i tested again, this time a heavy debug build - it seems that the debugger does not halt on every setted breakpoint (what i understand should not happen with heavy-debug)?

what i've done so far

1. fresh checkout of dosbox-svn (bad idea to use the svn version?)

2. build with vs2010 and following changed settings in src/platform/visualc/config.h <- the only changed source file compared to svn
#define C_DEBUG 1
#define C_SSHOT 0
#define C_MODEM 0
#define C_IPX 0
#define C_HEAVY_DEBUG 1
#define C_DYNAMIC_X86 0

3. using clean dosbox-SVN.conf with
- core=normal
- mount + debug game.exe start to ease my testing and check if the correct config is loaded

4. press F5 in debug, the game itself is running fine with heavy debug build

5. restart dosbox, set breakpoint in proc that i will reach (its an unconditional call to it in the first 5 opcodes of main function)
and step with F10/F11 to the breakpoint-position and see the corresponding line colored in red <- test the correct breakpoint position

6. restart dosbox, set breakpoint as before and press F5 -> then the debugger will just run over the setted breakpoint and the game starts
- that does not happen with all breakpoint - it works always for the main proc?

any ideas - more setting changes needed in config.h or dosbox-SVN.conf?

the game does not use any special anti-debug-tricks or stuff like that

i think i've found it - seems to be a regression with the bp-cmd or the break point handling

i reduced my testcase down to a small screenshot

it works if i set a breakpoint using the dosbox shown segment/offsets
but if i use an segment/offset pair that points to the same 32bit location but using different segment/offset values
dosbox will only colore the line red but will not halt on pressing F5

in debugger:

BP 1ED3:0025
- line gets colored red
- F5 stops on 1ED3:0025

convert 1ED3:0025 to 32-bit offset and convert back to 16-bit segment/offset

BP 1ED5:0005
- line gets colored red
- F5 does not stop on 1ED3:0025

i can use "C 1ED5:0005" without any problem to get to the code

this is how i produce a non-working but stilll valid segment/offset out of the dosbox shown segment/offset

1int offset32 = 0x1ED3 * 16 + 0x0025;
2int my_segment = offset32 / 16;
3int my_offset = offset32 % 16;
4assert(offset32 == my_segment * 16 + my_offset);
5//dosbox-ptr: 1ED3:0025
6//offset32: 0x0001ed55
7//my-ptr: 1ED5:0005

the problem is that i generate BP positions from other source not following the dosbox schema - but that shouldn't (of my understand) be a
problem at all

i've added a simple nasm hello.asm and the resulting hello.com to reproduce the problem

Physical breakpoints look for an exact match of the specified segment and offset. It's been like that as far back as 0.60 (I didn't check earlier), so how is it a regression?

This change to debug.cpp will allow breakpoints to stop at the same effective address at the cost of additional computation per executed instruction:

1-       if ((bp->GetType()==BKPNT_PHYSICAL) && bp->IsActive() && (bp->GetSegment()==seg) && (bp->GetOffset()==off)) {
2+       if ((bp->GetType()==BKPNT_PHYSICAL) && bp->IsActive() && (GetAddress(bp->GetSegment(),bp->GetOffset())==GetAddress(seg,off))) {

It could be better optimized by storing the 32-bit address in the breakpoint object and only computing the address on the currently executing segment and offset.

It's not a regression, but it is defintely something to be aware off.
Storing the 32 bit address sounds like a good solution.

Ah, the address is already being stored, so the more optimized change is:

1-       if ((bp->GetType()==BKPNT_PHYSICAL) && bp->IsActive() && (bp->GetSegment()==seg) && (bp->GetOffset()==off)) {
2+       if ((bp->GetType()==BKPNT_PHYSICAL) && bp->IsActive() && (bp->GetLocation()==GetAddress(seg,off))) {

I'll test it like this for awhile to see if there are any issues.

It's not a regression

but annoying enough to be near to

Ah, the address is already being stored, so the more optimized change is:...
I'll test it like this for awhile to see if there are any issues.

so it can become standard then in svn (real) soon now 😀 thx

and the red line drawing also not work properply all the time - hope this change will fix that too

@ripsaw8080 - thx to your fix - now all my former not/partial working breakpoints work now

but still the red line is sometime not shown on the breakpoint line (seem to be something similar)

i've found this code in debug.cpp responsible for the red background - and it seems to be correct, maybe my exprectations are wrong

1} else if (CBreakpoint::IsBreakpointDrawn(start)) {
2	wattrset(dbg.win_code,COLOR_PAIR(PAIR_GREY_RED));	

@ripsaw8080

i've patched and debugged some games over the last weeks and i would say the fix is working enough for svn integration

thx

I've noticed one drawback with this change to the debugger: breakpoints intended for when the processor is in protected mode won't work if set while the processor is in real mode, and vice versa. Before the change it didn't matter if a segment or a selector was specified. This could be resolved by adding something like BPR (real) and BPP (protected) commands in the debugger that aren't based on the current processor mode, but the BP command and F9 key would still use the current processor mode. Not sure if it's worth the trouble, though.