From patchwork Thu Feb 14 16:42:34 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Thomas Schwinge X-Patchwork-Id: 31477 Received: (qmail 33259 invoked by alias); 14 Feb 2019 16:42:47 -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 33250 invoked by uid 89); 14 Feb 2019 16:42:46 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-26.9 required=5.0 tests=BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_NONE, SPF_PASS autolearn=ham version=3.3.2 spammy=heh X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 14 Feb 2019 16:42:44 +0000 Received: from svr-orw-mbx-05.mgc.mentorg.com ([147.34.90.205]) by relay1.mentorg.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-SHA384:256) id 1guK5y-0004Sm-Pl from Thomas_Schwinge@mentor.com ; Thu, 14 Feb 2019 08:42:42 -0800 Received: from SVR-ORW-MBX-09.mgc.mentorg.com (147.34.90.209) by SVR-ORW-MBX-05.mgc.mentorg.com (147.34.90.205) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 14 Feb 2019 08:42:40 -0800 Received: from tftp-cs (147.34.91.1) by SVR-ORW-MBX-09.mgc.mentorg.com (147.34.90.209) with Microsoft SMTP Server id 15.0.1320.4 via Frontend Transport; Thu, 14 Feb 2019 08:42:40 -0800 Received: by tftp-cs (Postfix, from userid 49978) id 8F972C2320; Thu, 14 Feb 2019 08:42:39 -0800 (PST) From: Thomas Schwinge To: Pedro Alves , CC: <834575@bugs.debian.org>, <834575-forwarded@bugs.debian.org>, , Subject: Re: [pushed][PATCH v3 1/4] Extended-remote follow exec In-Reply-To: <49527ebd-a1b3-fff2-fc59-bb557e6d0c50@redhat.com> References: <1441996698-12694-1-git-send-email-donb@codesourcery.com> <87vauuiqkj.fsf@euler.schwinge.homeip.net> <49527ebd-a1b3-fff2-fc59-bb557e6d0c50@redhat.com> User-Agent: Notmuch/0.9-125-g4686d11 (http://notmuchmail.org) Emacs/25.2.2 (x86_64-pc-linux-gnu) Date: Thu, 14 Feb 2019 17:42:34 +0100 Message-ID: <87a7iyiao5.fsf@euler.schwinge.homeip.net> MIME-Version: 1.0 Hi! On Fri, 17 Feb 2017 16:45:01 +0000, Pedro Alves wrote: > Only noticed this patch now. Heh, and I've only now gotten back to completing this. ;-) > > On GNU/Hurd, there is no "#define PATH_MAX", so this fails to build. > > (I'm aware that there is other PATH_MAX usage in GDB sources, which we > > ought to fix at some point, for example in gdbserver -- which is not yet > > enabled for GNU/Hurd.) > > > > OK to push the following? (Similar to Svante's patch in > > .) > > > > > > --- gdb/remote.c > > +++ gdb/remote.c > > @@ -6927,7 +6927,6 @@ Packet: '%s'\n"), > > else if (strprefix (p, p1, "exec")) > > { > > ULONGEST ignored; > > - char pathname[PATH_MAX]; > > int pathlen; > > > > /* Determine the length of the execd pathname. */ > > @@ -6936,11 +6935,12 @@ Packet: '%s'\n"), > > > > /* Save the pathname for event reporting and for > > the next run command. */ > > + char *pathname = (char *) xmalloc (pathlen + 1); > > hex2bin (p1, (gdb_byte *) pathname, pathlen); > > pathname[pathlen] = '\0'; > > > hex2bin can throw, so wrap with a cleanup: > > char *pathname = (char *) xmalloc (pathlen + 1); > struct cleanup *old_chain = make_cleanup (xfree, pathname); > hex2bin (p1, (gdb_byte *) pathname, pathlen); > pathname[pathlen] = '\0'; > discard_cleanups (old_chain); > > OK with that change. Thanks; pushed to master the attached commit b671c7fb21306ce125717a44c30a71686bd24db1 "[gdb, hurd] Avoid using 'PATH_MAX' in 'gdb/remote.c'". Grüße Thomas From b671c7fb21306ce125717a44c30a71686bd24db1 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Fri, 17 Feb 2017 16:45:01 +0000 Subject: [PATCH] [gdb, hurd] Avoid using 'PATH_MAX' in 'gdb/remote.c' ..., which is not defined in GNU/Hurd systems, and so commit 94585166dfea8232c248044f9f4b1c217dc4ac2e "Extended-remote follow-exec" caused: [...]/gdb/remote.c: In member function 'void remote_target::remote_parse_stop_reply(const char*, stop_reply*)': [...]/gdb/remote.c:7343:22: error: 'PATH_MAX' was not declared in this scope char pathname[PATH_MAX]; ^~~~~~~~ gdb/ * remote.c (remote_target::remote_parse_stop_reply): Avoid using 'PATH_MAX'. --- gdb/ChangeLog | 6 ++++++ gdb/remote.c | 6 ++++-- 2 files changed, 10 insertions(+), 2 deletions(-) diff --git a/gdb/ChangeLog b/gdb/ChangeLog index f2bbd77558..bb27f74de1 100644 --- a/gdb/ChangeLog +++ b/gdb/ChangeLog @@ -1,3 +1,9 @@ +2019-02-14 Thomas Schwinge + Pedro Alves + + * remote.c (remote_target::remote_parse_stop_reply): Avoid using + 'PATH_MAX'. + 2019-02-14 David Michael Samuel Thibault Thomas Schwinge diff --git a/gdb/remote.c b/gdb/remote.c index 18e678d07a..85af01e4b7 100644 --- a/gdb/remote.c +++ b/gdb/remote.c @@ -7340,7 +7340,6 @@ Packet: '%s'\n"), else if (strprefix (p, p1, "exec")) { ULONGEST ignored; - char pathname[PATH_MAX]; int pathlen; /* Determine the length of the execd pathname. */ @@ -7349,11 +7348,14 @@ Packet: '%s'\n"), /* Save the pathname for event reporting and for the next run command. */ + char *pathname = (char *) xmalloc (pathlen + 1); + struct cleanup *old_chain = make_cleanup (xfree, pathname); hex2bin (p1, (gdb_byte *) pathname, pathlen); pathname[pathlen] = '\0'; + discard_cleanups (old_chain); /* This is freed during event handling. */ - event->ws.value.execd_pathname = xstrdup (pathname); + event->ws.value.execd_pathname = pathname; event->ws.kind = TARGET_WAITKIND_EXECD; /* Skip the registers included in this packet, since -- 2.19.2