hbreak reads memory

Yao Qi qiyaoltc@gmail.com
Tue Aug 2 08:44:00 GMT 2016

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

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