puzzled at sw/hw breakpoint

HW breakpoint requires a register that is compared to the PC. When the breakpoint register and the PC match, an interrrupt is generated. SW breakpoint entails replacing the instruction at the breakpoint location with a jump into the debugger. When resuming execution, the original instruction is replaced and execution transferred to that point.

Breakpoints generally involve execution paths only. Breaking on access to data is a different situation. Usually requires HW support to compare data addresses and generate an interupt.

The side affects of these are...

With HW breakpoints, the instruction at the breakpoint is executed and execution stops 1 instruction beyond the breakpoint. With SW breakpoints, execution stops at the breakpoint enabling you to single step through the instruction at the breakpoint.

Doug Dotson

I too see a 'problem' with Harvard architech: since the PC and code areas is not 'visible' ?

== Chris Glur.

Why? Doesn't that depend on the implementation? If the 'break' event is produced by a comparator comparing the PC against a register, it would occur the very moment the PC contains the matching address after the previous instruction is finished, and before the current (the one at the breakpoint) is even fetched from memory.

Meindert

I think this would depend upon implementation. In any case the debugger would set the break register with the address of the instruction prior to the desired breakpoint location so that the traditional behavior is achieved.

Doug

Ah, now I see what you were getting at. I haven't use a Harvard arch chip in many years (8048 family). In that case we had an ICE. I suspect that most these days have a JTAG interface for HW debugging.

Doug

That technique fails when the break location is the target of a branch or call instruction, which is often the case.

Thad

I might add, however, that for those particularly difficult-to-find somebody-corrupted-my-memory-location stray-pointer problems, HW data breakpoints rock.

On Sat, 27 Sep 2003 05:40:20 GMT, "ZO" wrote in comp.arch.embedded:

Please don't top-post, it makes technical threads difficult to follow. I've moved your material to the bottom and added my comments.

This is very dependent on the architecture. Earlier and smaller processors behave the way you say. But newer and larger processors, basically anything with a built-in MMU, has the facilities to abort any instruction after it has started but before is has completed, and this feature can be used for hardware breakpoints as well.

The TX2 had three "meta bits" added to each word. These enabled the hardware to perform a trap when the bits were seen, whereupon the software would determine whether the location had been used as (1) an instruction, (2) data, or (3) as an indirect address, or any combination of those.

This was cool because the program would run at full speed until (let's say) it modified itself!

Rick Merrill

Many many moons ago I built a system for my 8080 based machines. The 8080 signalled whether it was making an instruction fetch or data access, and whether the access was for read or write (fetches were always for read). My system had a single manually set breakpoint, using toggle switches, and the appropriate conditions. When that was found it set the 'wait' signal to the processor, so everything stopped.

This could be set to monitor any memory address. When it hit I could just use the interrupt button to force the execution of the system trap routine, which then captured the full status.

This was NOT a S100 buss system. I could set "don't care" conditions for the read/write/fetch bits, or for any address bit.

The result handled ROM code, found wayward pointers, etc. It was purely an accessory board which plugged into the backplane.

Could you elaborate this in more details? Actually that is one of the points puzzling me: Harvard arch means that instruction and data buses are saparate. Then how come you say that "code area is not visible"? I guess I need to go back grab my college textbook to review some sections again... Could someone quickly remind me what exactly is the processing flow in Harvard arch? I just wonder how do all these things come from one basic fact: processor has I side and D side......

Thanks.

In that case, what were to happen if the break point address was reached by a jump/branch from another location?? In this case, the breakpoint would be missed completely missed.

However, I suppose that other posters are correct that this could be implementation specific. I'm curious to know what the exceptions are. Can someone share that with the group?

-ZO

breakpoints,

the

sure

to

location

compare