[cdt-debug-dev] Re: hardware breakpoints (Freehill Christopher-RAT063)

[Duane Ellis <duane_ellis@xxxxxxxxxxxx>]

chris> We're looking at implementing hardware breakpoints 
chris> (HW BPs) and would like to get feedback to see what
chris> other ideas people have about how HW BPs should be 
chris> supported, and what, if anything, could be shared 
chris> with the community. We've implemented some of this,
chris> but would like feedback before going much further.

I use HW breakpoints OFTEN when debugging kernel type issues. 

I've got some concerns about what you are suggesting.

See below.

Duane Ellis
Principal Engineer
Franklin Electronic Publishers
One Franklin Plaza
Burlington NJ 08016
email: duane_ellis@xxxxxxxxxxxx
voice: 1-609-386-2500 x4918
skype: duane_ellis


------------------------------------------------------

> We've implemented some of this, but would like feedback
> before going much further.

These are my use cases...

Please don't forget about HW rd/wr breakpoints, size 
access, range masking and stuff like that.

I often use hardware breakpoints as follows:

I often times must debug multiply chained boot loaders. I 
often use explicit hardware instruction breakpoints. For 
example - I know the hard address the Nth in a series boot 
loader will eventually get to.

i set a HW instruction breakpoint, "load-symbols - no code". 
Hard reset and run till the breakpoint. 

I also have to actually debug ROM images.

Another example - is 'un hibernate' code (ie: device has 
turned off and the "turn back on code" is buggy). For 
example code is written to storage - power is removed, 
then restored. It's funny in a way the software breakpoint 
opcodes get saved in the hibernate device and restored. 
Sometimes the debugger goes knutzoid and gets out of sync.

Another example is debugging an application that lives in 
virtual memory. Often times - it's an app that is doing 
something... what I don't know and it is causing the kernel 
to crash... I set a hardware breakpoint at a specific virtual 
address boot .. run till the breakpoint 

------------------------------------------------------------

I often times use HW breakpoints to debug random memory corruption
typically caused by a loose or invalid pointer. 

A slight side suggestion:

        Chris - you work for Freescale... here's an idea 
        for you: (And you ARM guys on this list) Please add
        this feature to the SILICON!!!!!! people will like this. 

        How about tying some software features into them so 
        the *RUNNING* app can modify/set HW breakpoints!

        Ever debug random loose/wild pointer bugs?

        Imagine: Being able to MALLOC() memory dynamically
        and setting a hardware breakpoint on that memory
        so you can see why your heap is getting trashed.
 
        Or ... setting a dynamic HW breakpoint on the 
        runtime stack, ever debug a STACK buffer overflow?

        On ARM - give me a run time code access to the
        embedded ice macrocell present on *EVERY* arm CPU.
        I know the ETM has this... sort of.. but not
        the simple standard debug hw breakpoints.

------------------------------------------------------------

> Our current thinking is to add a sibling menu item to 
> "Toggle Breakpoint" called "Toggle Hardware Breakpoint". 
> "Toggle Breakpoint" would mean the user would want to set 
> an auto breakpoint. By auto breakpoint, I mean, if possible, 
> set a software breakpoint (SW BP), and if that fails, set a 
> HW BP. The idea being that a user would normally want to 
> use SW BPs, but sometimes (for example, in ROM) this isn't
> possible.

The three debuggers I use today have different means to do this.

The EDB (epi toools/mentor graphics, Mentor also has an eclipse
based debugger) - it is a right click menu or a dialog box. 
Default click - sets a normal breakpoint, right click I can 
do more.

In the EDB case, it is an ARM9 based target.

The EDB debugger - and others I've used auto-promote 
breakpoints from soft to hard. Often - when you are single 
stepping you must create temp breakpoints to step-over an 
interrupt or a subroutine call. These temp breakpoints also 
need to be auto-promoted.

What sucks is in some cases (ie: ARM) there are only 2 hw 
breakpoints as a user I have to be mindful if I am stepping 
through a ROM - I have to make certain there is at least one
free HW breakpoint for the debugger to use - otherwise the 
debugger gets lost and my only solution is to RESET and start 
debugging again... GRRRRR......

Other debuggers [actually full-chip simulators back-ends
for GDB I wrote for our custom CPUs] have rather complex 
rd/wr breakpoint schemes - and because they are 'software' 
devices not real hardware - they have hundreds of hardware 
breakpoints.

------------------------------------------------------

> For explicitly set HW BPs, and BPs that are HW BPs as a 
> result of setting an auto breakpoint, a decorator would 
> be added to the blue dot icon that indicates that the 
> breakpoint is a hardware breakpoint. 

The debuggers I use do this: RED dot - normal breakpoint, 
Blue dot - HW. red/blue circles indicate disabled 
breakpoints. GDB/TK/Insight uses a stop sign.

------------------------------------------------------

> To clear a HW BP, a user could either click on "Toggle 
> Breakpoint" or "Toggle Hardware Breakpoint". To remove 
> a non-HW BP, the user would either double click the BP,
> or click on "Toggle Breakpoint"; "Toggle Hardware 
> Breakpoint" would be disabled. The reasoning being that 
> a HW BP is a BP, but the reverse isn't true; i.e., if 
> an auto BP resulted in successfully setting a SW BP, 
> it would not make sense to be able to "Toggle Hardware 
> Breakpoint" on that BP.

Oh yes it would - I was doing this yesterday tracking 
down a boot loader bug, in my case, I wanted to set a 
breakpoint at a specific virtual address that was not 
initially available (the MMU not setup yet)

In my case - to get back to where I was I promoted the
breakpoint to a HW breakpoint. Exited - rebuilt the
app and started the process.

------------------------------------------------------

> Persistence of breakpoints would be handled as follows:
> -BPs explicitly set as HW BPs would remain HW BPs on 
> subsequent debugger sessions

I disagree with some of your statements below, I would 
state all of this in a very simple way:

        What I saved - is what I should restore. 
        No more, No less, No changes.

        I find it most frustrating when things change
        on me for no apparent reason.

        If it cannot restore the previous session
        it should tell me with some type of dialog.

------------------------------------------------------

> -BPs that are HW as a result of setting an auto breakpoint 
> would remain auto in subsequent debug sessions. For example,
> say in the first session a user sets an auto BP, but software
> breakpoints are not available at the indicated location, so 
> a HW BP gets set. Then, the user kills the session and changes 
> the HW so that a SW BP can now be set at the location in 
> question. Since the user originally set an auto BP, a SW BP
> should be set and not a HW BP.

Maybe I don't see enough of this... 

How exactly would the hardware change? 

What if for example the exact opposite occurs. At reset - that 
memory area is RD/WR because the system is in Supervisor mode. 
But ... I was originally debugging a USER mode app - and the 
kernel has flipped some hardware bit and now it is read only.

In this example - the breakpoint originally was/should be 
"promoted" and a user message should appear - "Breakpoint 
promoted to HW Breakpoint" - or "No more HW Breakpoints 
available"

Another reverse is the chip selects are not yet configured 
at HW reset. In some cases, the debugger can poke values and 
configure them. In other cases - well the kernel you are 
using will reconfigure or probe them - no mater what you do.

Another example is virtual memory via the MMU.

Once told what type of breakpoint it is - as indicated by the
icon in the source code - it should not change magically. That 
would be just impossible to deal with.

This exact case also occurs when you are debugging mixed 
KERNEL/USER mode code.  When you click STOP with a JTAG
debugger - where does the debugger stop? In user-land or 
kernel-land?  Suddenly memory access changes.

In a multitasking system, a some other task with it's virtual 
memory configuration setup.