From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21404 invoked by alias); 11 Apr 2012 08:41:41 -0000 Received: (qmail 21373 invoked by uid 22791); 11 Apr 2012 08:41:38 -0000 X-SWARE-Spam-Status: No, hits=-6.3 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 11 Apr 2012 08:41:15 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q3B8fB3j022873 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 11 Apr 2012 04:41:11 -0400 Received: from host2.jankratochvil.net (ovpn-116-17.ams2.redhat.com [10.36.116.17]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q3B8f4nI013152 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 11 Apr 2012 04:41:07 -0400 Date: Wed, 11 Apr 2012 08:45:00 -0000 From: Jan Kratochvil To: Yao Qi Cc: gdb-patches@sourceware.org Subject: Re: [patch] More suggestive displaced-stepping memory error message Message-ID: <20120411084104.GA21919@host2.jankratochvil.net> References: <20120410191955.GB31331@host2.jankratochvil.net> <4F84C2D7.1070203@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F84C2D7.1070203@codesourcery.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2012-04/txt/msg00232.txt.bz2 On Wed, 11 Apr 2012 01:31:35 +0200, Yao Qi wrote: > On 04/11/2012 03:19 AM, Jan Kratochvil wrote: > > - read_memory (copy, displaced->step_saved_copy, len); > > + status = target_read_memory (copy, displaced->step_saved_copy, len); > > + if (status != 0) > > + throw_error (MEMORY_ERROR, > > + _("Error accessing memory address %s (%s) for " > > + "displaced-stepping buffer, you may want to temporarily " > > + "turn it off if there is only one inferior thread."), > > The error message is not clear to me. Why "one inferior thread" matters > here? Because with only one inferior thread you can "set displaced-stepping off" without any disadvantages. If you have more threads then sure "set displaced-stepping off" can have performance side-effects. As I expect this problem can happen (or at least happened for me) only during very early inferior initialization then the user sees there is only one thread and therefore the user can easily do "set displaced-stepping off". But I was not sure if this suggestion makes too much sense so I am fine to put there just the message explaining it happened with "displaced-stepping buffer", user should figure out how to workaround it himself/herself. > If GDB is unable to do displaced-stepping due to unavailable > scratch pad, user has no choice except disable displaced-stepping for a > moment, and turn it on later. > > > + paddress (target_gdbarch, copy), safe_strerror (status)); > ^^^^^^^^^^^^^^ why not `gdbarch'? copy-paste mistake, thanks. > Probably, GDB can be smart enough to not > use displaced stepping when get error on accessing scratch pad. ... and there is only one inferior thread. As if there are more threads it would be bad to hide the displaced-stepping buffer problem from the user while affecting performance / non-stop mode of the other threads. > So far, > displaced_step_prepare returns 1 for success and 0 for queued request. > We can add one more return value -1 for `unable to do displaced > stepping', so that caller can go non-displaced-stepping path. We could discuss first more the cases when it can happen and it is not some GDB bug. So far I know only about the ld.so initialization. As I see there are concerns about the message I will just check in this part, it should be sufficient for troubleshooting. Thanks, Jan gdb/ 2012-04-11 Jan Kratochvil Provide more specific displaced-stepping memory error message. * infrun.c (displaced_step_prepare): New variable status. Call target_read_memory instead of read_memory, provide more specific error message. --- a/gdb/infrun.c +++ b/gdb/infrun.c @@ -1296,6 +1296,7 @@ displaced_step_prepare (ptid_t ptid) ULONGEST len; struct displaced_step_closure *closure; struct displaced_step_inferior_state *displaced; + int status; /* We should never reach this function if the architecture does not support displaced stepping. */ @@ -1356,7 +1357,12 @@ displaced_step_prepare (ptid_t ptid) displaced->step_saved_copy = xmalloc (len); ignore_cleanups = make_cleanup (free_current_contents, &displaced->step_saved_copy); - read_memory (copy, displaced->step_saved_copy, len); + status = target_read_memory (copy, displaced->step_saved_copy, len); + if (status != 0) + throw_error (MEMORY_ERROR, + _("Error accessing memory address %s (%s) for " + "displaced-stepping scratch space."), + paddress (gdbarch, copy), safe_strerror (status)); if (debug_displaced) { fprintf_unfiltered (gdb_stdlog, "displaced: saved %s: ",