hbreak reads memory
Alexandru-Adrian Oltean
adrian.oltean@nxp.com
Thu Jul 28 06:28:00 GMT 2016
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
Regarding your suggestions, I know for sure that setting memory areas read-only or inaccessible helps. The other
suggestion involving 'set trust-readonly-sections' seems to allow gdb to access memory. However, I'd avoid
managing memory zones this way since HW breaks should really not touch memory at all.
Thanks,
Adrian
-----Original Message-----
From: Breazeal, Don [mailto:Don_Breazeal@mentor.com]
Sent: Thursday, July 28, 2016 12:42 AM
To: Alexandru-Adrian Oltean <adrian.oltean@nxp.com>; gdb@sourceware.org
Subject: RE: hbreak reads memory
Adrian,
I think this is due to some function prologue analysis. You might try setting the breakpoint on an address, e.g. instead of 'hbreak foo' use 'hbreak *foo'. The breakpoint should then be on the address of the entry point to the function and the memory accesses may be reduced or eliminated.
You might also try 'set trust-readonly-sections' and/or set mem inaccessible-by-default. Those may or may not help.
--Don
> -----Original Message-----
> From: gdb-owner@sourceware.org [mailto:gdb-owner@sourceware.org] On
> Behalf Of Alexandru-Adrian Oltean
> Sent: Tuesday, July 26, 2016 11:29 PM
> To: gdb@sourceware.org
> Subject: hbreak reads memory
>
> Hi everyone,
>
> I noticed that setting a hardware break using hbreak will trigger a
> memory access at the address where the breakpoint is supposed to be
> installed. Can someone explain why is that memory access needed? I'm
> thinking that we might be in a situation where that memory area is not
> yet initialized/accessible (maybe MMU not configured yet) and the
> access corrupts the debugged target.
>
> Thanks,
> Adrian
More information about the Gdb
mailing list