hbreak reads memory

hbreak reads memory

[Alexandru-Adrian Oltean]

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

RE: hbreak reads memory

[Breazeal, Don]

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

RE: hbreak reads memory

[Alexandru-Adrian Oltean]

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

RE: hbreak reads memory

[Alexandru-Adrian Oltean]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="gb2312", Size: 3123 bytes --]

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

\x16º&ÖëzÛ«ŸŽvÓ¹b²Ö«r\x18\x1d

RE: hbreak reads memory

[Alexandru-Adrian Oltean]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 2514 bytes --]

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.

Thanks,
Adrian

-----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
/home/yao/SourceCode/gnu/gdb/git/gdb/target.c:1459
#10 0x00000000006c537d in program_breakpoint_here_p (gdbarch=0x621000139d10, address=67336) at
/home/yao/SourceCode/gnu/gdb/git/gdb/breakpoint.c:9135
#11 0x00000000006c5677 in bp_loc_is_permanent (loc=0x613000018a00) at
/home/yao/SourceCode/gnu/gdb/git/gdb/breakpoint.c:9165
#12 0x00000000006c51c9 in add_location_to_breakpoint (b=0x611000229380, sal=0x7fff9a2ab7d0) at
/home/yao/SourceCode/gnu/gdb/git/gdb/breakpoint.c:9102
#13 0x00000000006be6a9 in init_raw_breakpoint (b=0x611000229380, gdbarch=0x62100017d510, sal=..., bptype=bp_hardware_breakpoint,
    ops=0x13d6200 <bkpt_breakpoint_ops>) at
/home/yao/SourceCode/gnu/gdb/git/gdb/breakpoint.c:7595

--
Yao (齐尧)
\x16º&ÖëzÛ«ŸŽvÓÙb²Ö«r\x18\x1d