From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-prs-return-16622-listarch-gdb-prs=sources.redhat.com@sourceware.org>
Received: (qmail 4742 invoked by alias); 16 Sep 2014 15:10:18 -0000
Mailing-List: contact gdb-prs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb-prs.sourceware.org>
List-Subscribe: <mailto:gdb-prs-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb-prs/>
List-Post: <mailto:gdb-prs@sourceware.org>
List-Help: <mailto:gdb-prs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: gdb-prs-owner@sourceware.org
Received: (qmail 4714 invoked by uid 48); 16 Sep 2014 15:10:17 -0000
From: "palves at redhat dot com" <sourceware-bugzilla@sourceware.org>
To: gdb-prs@sourceware.org
Subject: [Bug gdb/17384] android arm gdb "Cannot access memory at address"
 when I "stepi" over "blx"
Date: Tue, 16 Sep 2014 15:10:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gdb
X-Bugzilla-Component: gdb
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: palves at redhat dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-17384-4717-YeVJqKpAqZ@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-17384-4717@http.sourceware.org/bugzilla/>
References: <bug-17384-4717@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-q3/txt/msg00611.txt.bz2

https://sourceware.org/bugzilla/show_bug.cgi?id=17384

--- Comment #6 from Pedro Alves <palves at redhat dot com> ---
> If I put a breakpoint on memory_error_message() instead, which is the function 
> that prints the actual error. Then I get one hit only, and from this stack: 

That doesn't print the error, it only builds the error string.

But I see where it's printed:

 #5  0x0000000000564fae in catch_errors (func=0x60a72d 
<do_captured_read_memory_integer>, func_args=0x7fffcfde1c80, errstring=0x848451
"", mask=RETURN_MASK_ALL) at exceptions.c:237
 #6  0x000000000060a7cb in safe_read_memory_integer (memaddr=1, len=4,
byte_order=BFD_ENDIAN_LITTLE, return_value=0x7fffcfde1d00) at corefile.c:343

It's catch_errors itself:

int
catch_errors (catch_errors_ftype *func, void *func_args, char *errstring,
          return_mask mask)
{
...
  exception_fprintf (gdb_stderr, exception, "%s", errstring);
  if (exception.reason != 0)
    return 0;
  return val;
}

Eh, that's unexpected.

This means that safe_read_memory_integer is not silent on error.  This seems
bogus to me.  It should probably be using catch_exceptions instead.

Of course, that still doesn't explain why we try to read address 0x1 in the
first place.

-- 
You are receiving this mail because:
You are on the CC list for the bug.