RE: hbreak reads memory

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:[email protected]] 
Sent: Thursday, July 28, 2016 12:42 AM
To: Alexandru-Adrian Oltean <[email protected]>; [email protected]
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: [email protected] [mailto:[email protected]] On 
> Behalf Of Alexandru-Adrian Oltean
> Sent: Tuesday, July 26, 2016 11:29 PM
> To: [email protected]
> 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