From patchwork Fri Jul 11 09:58:25 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Pedro Alves X-Patchwork-Id: 2032 Received: (qmail 27205 invoked by alias); 11 Jul 2014 09:58:33 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 27195 invoked by uid 89); 11 Jul 2014 09:58:32 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL, BAYES_00, RP_MATCHES_RCVD, SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 11 Jul 2014 09:58:30 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s6B9wQei017215 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 11 Jul 2014 05:58:27 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s6B9wPUX024425; Fri, 11 Jul 2014 05:58:26 -0400 Message-ID: <53BFB541.9020705@redhat.com> Date: Fri, 11 Jul 2014 10:58:25 +0100 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Adrian Sendroiu , gdb-patches@sourceware.org Subject: Re: [PATCH] call remote_check_symbols after attaching References: <1405070240-11462-1-git-send-email-adrian.sendroiu@freescale.com> In-Reply-To: <1405070240-11462-1-git-send-email-adrian.sendroiu@freescale.com> Hi Adrian, On 07/11/2014 10:17 AM, Adrian Sendroiu wrote: > When debugging a remote bare-metal target with > "target extended-remote" + attach, gdb won't send a qSymbol packet to initiate > symbol lookup. This happens because all the previous places in which gdb might > have done this are guarded by conditions that don't hold in the said scenario: > there are no shared libraries, no vsyscall page and the binary file didn't > change in the time passed between the "file" and the "attach" commands. > > To solve this problem remote_check_symbols is called in the post_attach hook. > > gdb: > > 2014-07-11 Adrian Sendroiu > > * remote.c: call remote_check_symbols after attaching This should list the "what": the new function, and the other function that changed. Entries should be full sentences starting with capital letter and ending with a full stop. E.g.,: 2014-07-11 Adrian Sendroiu * remote.c (extended_remote_post_attach): New function. (init_extended_remote_ops): Install it as to_post_attach method. See the numerous examples in the ChangeLog file. > +/* Implementation of the to_post_attach method */ Full stop and double space after period missing. > + > +static void > +extended_remote_post_attach (struct target_ops *ops, int pid) > +{ > + /* In certain cases gdb might not have had the chance to start symbol lookup > + up until now. This could happen if the debugged binary is not using > + shared libraries, the vsyscall page is not present and the binary itself > + hadn't changed since the debugging process was started */ Likewise. I went ahead and did these changes (and similar to the git log entry) for you, and pushed the patch in, as below. Thanks! -------------------- From b9c1d481cc639a9c1f31aea164f8716a85edd89f Mon Sep 17 00:00:00 2001 From: Adrian Sendroiu Date: Fri, 11 Jul 2014 10:51:48 +0100 Subject: [PATCH] remote: call remote_check_symbols after attaching When debugging a remote bare-metal target with "target extended-remote" + attach, GDB won't send a qSymbol packet to initiate symbol lookup. This happens because all the previous places in which GDB might have done this are guarded by conditions that don't hold in the said scenario: there are no shared libraries, no vsyscall page and the binary file didn't change in the time passed between the "file" and the "attach" commands. To solve this problem remote_check_symbols is called in the target_post_attach hook. gdb/ 2014-07-11 Adrian Sendroiu * remote.c (extended_remote_post_attach): New function. (init_extended_remote_ops): Install it as to_post_attach method. --- gdb/ChangeLog | 5 +++++ gdb/remote.c | 15 +++++++++++++++ 2 files changed, 20 insertions(+) diff --git a/gdb/ChangeLog b/gdb/ChangeLog index 56f2909..9aea5a9 100644 --- a/gdb/ChangeLog +++ b/gdb/ChangeLog @@ -1,3 +1,8 @@ +2014-07-11 Adrian Sendroiu + + * remote.c (extended_remote_post_attach): New function. + (init_extended_remote_ops): Install it as to_post_attach method. + 2014-07-09 Pedro Alves * infcmd.c (attach_command_post_wait): Don't call diff --git a/gdb/remote.c b/gdb/remote.c index 3aa030c..76efefa 100644 --- a/gdb/remote.c +++ b/gdb/remote.c @@ -4484,6 +4484,20 @@ extended_remote_attach (struct target_ops *ops, const char *args, int from_tty) extended_remote_attach_1 (ops, args, from_tty); } +/* Implementation of the to_post_attach method. */ + +static void +extended_remote_post_attach (struct target_ops *ops, int pid) +{ + /* In certain cases GDB might not have had the chance to start + symbol lookup up until now. This could happen if the debugged + binary is not using shared libraries, the vsyscall page is not + present (on Linux) and the binary itself hadn't changed since the + debugging process was started. */ + if (symfile_objfile != NULL) + remote_check_symbols(); +} + /* Check for the availability of vCont. This function should also check the response. */ @@ -11530,6 +11544,7 @@ Specify the serial device it is connected to (e.g. /dev/ttya)."; extended_remote_ops.to_mourn_inferior = extended_remote_mourn; extended_remote_ops.to_detach = extended_remote_detach; extended_remote_ops.to_attach = extended_remote_attach; + extended_remote_ops.to_post_attach = extended_remote_post_attach; extended_remote_ops.to_kill = extended_remote_kill; extended_remote_ops.to_supports_disable_randomization = extended_remote_supports_disable_randomization;