hbreak reads memory

Alexandru-Adrian Oltean adrian.oltean@nxp.com
Tue Aug 2 09:15:00 GMT 2016

Thanks Yao for explaining the origin of that memory access. So reading memory for a 
hbreak seems the expected behavior. My understanding was that setting a HW break 
would not imply a mem read operation and I'd simply have to deal with setting that
HW break inside my debug stub. But the access can't be avoided as far as I understand
from you.


-----Original Message-----
From: Yao Qi [mailto:qiyaoltc@gmail.com] 
Sent: Tuesday, August 02, 2016 11:44 AM
To: Alexandru-Adrian Oltean <adrian.oltean@nxp.com>
Cc: Breazeal, Don <Don_Breazeal@mentor.com>; gdb@sourceware.org
Subject: Re: hbreak reads memory

On Thu, Jul 28, 2016 at 7:28 AM, Alexandru-Adrian Oltean <adrian.oltean@nxp.com> wrote:
> Hi Don,
> I forgot to mention one important thing in my previous email - I'm setting breaks using addresses not symbols.
> So even with this approach I'm still seeing that memory is being 
> accessed. I'm expecting a hbreak on a given address to skip that function prologue analysis.
> Here's what I see when activating debug in gdb:
> hbreak *0xfff54d64
> Sending packet: $mfff54d64,4#36...Ack
> Packet received: E01
> Hardware assisted breakpoint 3 at 0xfff54d64

I don't think it is wrong for GDB to read that memory in 'hbreak'.  'hbreak'
means hardware breakpoint (rather than software breakpoint), so GDB shouldn't write breakpoint instruction to the address, but may need to read that piece of memory.  If the memory is unreadable, your debug stub returns error.

The reason of memory access of 'hbreak' is that GDB checks whether there has been a permanent breakpoint on that address or not.

#9  0x00000000008c2457 in target_read_memory (memaddr=67336,
myaddr=0x7fff9a2ab5e0 "\265\v", len=4) at
#10 0x00000000006c537d in program_breakpoint_here_p (gdbarch=0x621000139d10, address=67336) at
#11 0x00000000006c5677 in bp_loc_is_permanent (loc=0x613000018a00) at
#12 0x00000000006c51c9 in add_location_to_breakpoint (b=0x611000229380, sal=0x7fff9a2ab7d0) at
#13 0x00000000006be6a9 in init_raw_breakpoint (b=0x611000229380, gdbarch=0x62100017d510, sal=..., bptype=bp_hardware_breakpoint,
    ops=0x13d6200 <bkpt_breakpoint_ops>) at

Yao (齐尧)

More information about the Gdb mailing list