Guys, I have no experience in GDB development but what I've observed and reported below seems 
like a problem in my opinion. Do you agree? Hardware breakpoints should not touch memory. I'll try to 
debug and see what's happening exactly but first I thought I'd check with you whether current behavior 
is expected or not.

Thanks,
Adrian

-----Original Message-----
From: 高国胜 [mailto:guosheng_gao@realsil.com.cn] 
Sent: Thursday, July 28, 2016 9:32 AM
To: Alexandru-Adrian Oltean <adrian.oltean@nxp.com>; Breazeal, Don <Don_Breazeal@mentor.com>; gdb@sourceware.org
Subject: 答复: hbreak reads memory

Adrian,
 I think this is maybe due to delay slot analysis, GDB maybe need to adjust the breakpoint address.


-----邮件原件-----
发件人: gdb-owner@sourceware.org [mailto:gdb-owner@sourceware.org] 代表 Alexandru-Adrian Oltean
发送时间: 2016年7月28日 14:28
收件人: Breazeal, Don; gdb@sourceware.org
主题: 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: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

�&佒雤郢煄v庸b仓玶