From patchwork Wed Aug 29 19:34:52 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sergio Durigan Junior X-Patchwork-Id: 29113 Received: (qmail 54105 invoked by alias); 29 Aug 2018 19:34:57 -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 54090 invoked by uid 89); 29 Aug 2018 19:34:56 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-12.0 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_2, GIT_PATCH_3, SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=assure, exercise, pulled X-HELO: mx1.redhat.com Received: from mx3-rdu2.redhat.com (HELO mx1.redhat.com) (66.187.233.73) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 29 Aug 2018 19:34:54 +0000 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id E182B40216E7 for ; Wed, 29 Aug 2018 19:34:52 +0000 (UTC) Received: from localhost (unused-10-15-17-196.yyz.redhat.com [10.15.17.196]) by smtp.corp.redhat.com (Postfix) with ESMTP id B332A10B7CB6; Wed, 29 Aug 2018 19:34:52 +0000 (UTC) From: Sergio Durigan Junior To: Pedro Alves Cc: GDB Patches Subject: Re: [PATCH] Update gnulib to current upstream master References: <87bm9mnty0.fsf@redhat.com> Date: Wed, 29 Aug 2018 15:34:52 -0400 In-Reply-To: (Pedro Alves's message of "Wed, 29 Aug 2018 20:06:27 +0100") Message-ID: <87h8jdm0f7.fsf@redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 X-IsSubscribed: yes On Wednesday, August 29 2018, Pedro Alves wrote: > On 08/28/2018 08:59 PM, Sergio Durigan Junior wrote: >> [ Disclaimer: I'm sending the patch gzipped because I'm afraid >> sourceware won't accept a 1.2MB message. ] >> >> It has been a while since we don't update our gnulib copy against >> their upstream master branch, so I thought I'd propose this patch. It >> also fixes (at least) one bug reported against GDB: >> >> https://sourceware.org/bugzilla/show_bug.cgi?id=23558 >> >> The problem reported there is about the replacement of 'getcwd' when >> cross-compiling GDB. With our current gnulib copy, the mechanism for >> deciding whether to use the system's 'getcwd' or gnulib's version is >> too simplistic and pessimistic, so when cross-compiling we always end >> up using gnulib's version, which has a limitation: it cannot handle >> the situation when the parent directory doesn't have read permissions. >> >> This has been reported against upstream gnulib and the fix has been >> pushed here: >> >> https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=a96d2e67052c879b1bcc5bc461722beac75fc372 >> >> I regtested this patch on Fedora 28 x86-64, and there were no >> regressions. >> >> OK? > > It is standard practice when updating gnulib to discuss the set of > modules that the exercise brings in due to module dependencies. > If we're now including some more modules, that may mean that > we could eliminate some older host compatibility code from gdb > in favor of gnulib's and list the module dependencies > explicitly in IMPORTED_GNULIB_MODULES in update-gnulib.h. > > Conversely, there's a chance that we were depending on some > module that wasn't explicitly listed in IMPORTED_GNULIB_MODULES, > and an update could remove the module by mistake. Hm, OK, I didn't think about this scenario, so I didn't bother including the list of modules that were pulled when updating gnulib. So, I ran the gnulib update process twice, once for our previous version, and once for the new version (that I pushed). The differences are: --- /tmp/gnulib1.txt 2018-08-29 15:20:56.394418711 -0400 +++ /tmp/gnulib2.txt 2018-08-29 15:22:57.846895510 -0400 @@ -4,13 +4,14 @@ alloca-opt assure at-internal + builtin-expect + c99 canonicalize-lgpl chdir chdir-long cloexec close closedir - configmake d-ino d-type dirent @@ -30,6 +31,7 @@ fcntl fcntl-h fd-hook + fd-safer-flag fdopendir filename filenamecat-lgpl @@ -37,6 +39,7 @@ float fnmatch fnmatch-gnu + fnmatch-h fpieee fpucw frexp @@ -51,6 +54,7 @@ gettext-h gettimeofday glob + glob-h hard-locale include_next intprops @@ -59,8 +63,10 @@ isnand-nolibm isnanl-nolibm largefile + libc-config limits-h localcharset + localtime-buffer lstat malloc-posix malloca @@ -94,7 +100,7 @@ rmdir same-inode save-cwd - secure_getenv + scratch_buffer setenv signal-h snippet/_Noreturn @@ -103,8 +109,10 @@ snippet/warn-on-use ssize_t stat + stat-time + std-gnu11 stdbool stddef stdint stdio stdlib @@ -130,40 +138,36 @@ verify wchar wctype-h + xalloc-oversized It doesn't seem like we're importing any important module implicity, nor that we stopped important anything important, but I may be wrong. > Another reason for that is that that are some modules that > are problematic for us (e.g., the one that pulls in Windows's > select replacement), so we need to look out for that, in case > it is pulled in by a dependency. It seems we're still covered. > Also, if there were newer m4 files or m4 files deleted, I think we > we need to update the list in gnulib/Makefile.in (aclocal_m4_deps). As I said on IRC, I had no idea we needed to manually edit any other file, especially one that's under the gnulib/ dir. But I'll do it and propose a patch. > Should we cherry pick the getcwd fix to the 8.2 branch? If you're proposing cherry-picking only the patch to the .m4 file under the gnulib/ dir, then perhaps we could. Backporting the whole gnulib update is not a good idea, IMHO. But I'm sure that's not what you meant. Thanks, -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible http://sergiodj.net/