This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
RE: hbreak reads memory
- From: Alexandru-Adrian Oltean <adrian dot oltean at nxp dot com>
- To: Yao Qi <qiyaoltc at gmail dot com>
- Cc: "Breazeal, Don" <Don_Breazeal at mentor dot com>, "gdb at sourceware dot org" <gdb at sourceware dot org>
- Date: Tue, 2 Aug 2016 09:15:07 +0000
- Subject: RE: hbreak reads memory
- Authentication-results: sourceware.org; auth=none
- Authentication-results: spf=none (sender IP is ) smtp.mailfrom=adrian dot oltean at nxp dot com;
- References: <VI1PR0401MB2671E54864682705BFABFC6BF10F0@VI1PR0401MB2671.eurprd04.prod.outlook.com> <DA279C53C4A5884A907135DFCD7A059A37EF9758@NA-MBX-02.mgc.mentorg.com> <VI1PR0401MB2671279AAAF1C68AFEA36DF3F1000@VI1PR0401MB2671.eurprd04.prod.outlook.com> <CAH=s-PO2rUWbiFwMgtbsqDMNQnPB0fdmsmxe2HU9y4z7F7=pFQ@mail.gmail.com>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
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 (齐尧)