From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 107023 invoked by alias); 11 Sep 2018 00:38:10 -0000 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 Received: (qmail 107012 invoked by uid 89); 11 Sep 2018 00:38:09 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=HCc:D*fr, HTo:D*cx, investigated, smarter 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; Tue, 11 Sep 2018 00:38:07 +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 C7F5A400C3C0; Tue, 11 Sep 2018 00:38:05 +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 3B0BC10F1BE5; Tue, 11 Sep 2018 00:38:05 +0000 (UTC) From: Sergio Durigan Junior To: Rich Felker Cc: Romain Naour , Thomas Petazzoni , Romain Naour , buildroot@buildroot.org, gdb-patches@sourceware.org Subject: Re: [Buildroot] [PATCH 2/2] package/gdb: use stat() privided by the system References: <20180909163750.14196-1-romain.naour@gmail.com> <20180909163750.14196-2-romain.naour@gmail.com> <20180910174900.0b9f4133@windsurf> <20180910224128.GT1878@brightrain.aerifal.cx> Date: Tue, 11 Sep 2018 00:38:00 -0000 In-Reply-To: <20180910224128.GT1878@brightrain.aerifal.cx> (Rich Felker's message of "Mon, 10 Sep 2018 18:41:28 -0400") Message-ID: <87lg88oolv.fsf@redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2018-09/txt/msg00306.txt.bz2 On Monday, September 10 2018, Rich Felker wrote: > On Mon, Sep 10, 2018 at 11:20:58PM +0200, Romain Naour wrote: >> Hi Thomas, >>=20 >> Adding the gdb-patches ml and Rich Felker in Cc. >>=20 >> Le 10/09/2018 =C3=A0 17:49, Thomas Petazzoni a =C3=A9crit=C2=A0: >> > Hello, >> >=20 >> > On Sun, 9 Sep 2018 18:37:50 +0200, Romain Naour wrote: >> >> Use the same workaround [1] as gnulib use to get the original >> >> definition of stat. Otherwise with musl toolchains, gnulib try to use >> >> rpl_stat which is not defined. >> >> >> >> Fixes: >> >> https://gitlab.com/free-electrons/toolchains-builder/-/jobs/95552308 >> >> >> >> [1] http://git.savannah.gnu.org/cgit/gnulib.git/commit/lib/stat.c?id= =3Dc9d72f69bd201a1ab31464d91f234ea1817fe0e1 >> >> >> >> Signed-off-by: Romain Naour >> >> Cc: Thomas Petazzoni >> >=20 >> > I am confused by this patch. Why do we need that? The on >> > my system doesn't test __need_system_sys_stat_h. Is this a workaround >> > to force gnulib to not provide its own stat() replacement ? >> >=20 >> > Why is gnulib misbehaving here ? We have tons of gnulib related hacks >> > in gdb.mk, and this start to pile up quite a bit. Why do we have all >> > those gnulib issues with gdb ? Why not with tons of other packages that >> > also use gnulib ? >>=20 >> There are too many questions here, I can't answer. >> There are some (old) hack with coreutils like gl_cv_func_gettimeofday_cl= obber >> which is in Buildroot since a long time. I can't tell for every gnulib b= ased >> packages... >>=20 >> >=20 >> >> +Use the same workaround [1] as gnulib use to get the original >> >> +definition of stat. Otherwise with musl toolchains, gnulib try to use >> >> +rpl_stat which is not defined. >> >=20 >> > Well rpl_stat() is supposed to be implemented by gnulib. So basically >> > gnulib tells gdb: please don't use stat() but my rpl_stat() wrapper, >> > but then gnulib doesn't provide rpl_stat(). >> >=20 >> > Any idea what's happening here ? >>=20 >> As far I can tell, the regression has been introduced by this commit: >> https://sourceware.org/git/gitweb.cgi?p=3Dbinutils-gdb.git;a=3Dcommitdif= f;h=3D2441702a72f324e41a1624dc042b334f375e2d81 This is happening because, before the commit mentioned above, 'common-utils.c' (which gets transformed into 'common-utils-ipa.c' during the gdbserver build) wasn't calling 'stat'. It doesn't seem like a regression; it seems like a hidden problem that was uncovered by the need of 'stat'. I don't know why this problem is manifesting only when compiling IPA, and not when compiling 'common-utils.c' during GDB's/gdbserver's build. > I'm not aware of all the context, but it looks like different source > files disagree on whether gnulib has replaced stat or not -- the > gnulib source file thinks it hasn't, so the rpl_stat function isn't > defined, but gdb's common-utils-ipa.c file (or rather the gnulib > stat.h included into it?) thinks it has been replaced and is trying to > use the replacement. This is likely the result of an incorrect hack > somewhere. Do you know if it happens with upstream gdb and musl or > just in buildroot's package? Haven't really investigated, but be aware that there has been a recent attempt at updating our local gnulib copy, which unfortunately introduced a bunch of build failures and had to be reverted (even though I don't really see how 'stat' could be affected). I'm not sure if you are using the latest git HEAD or not (it seems like you aren't, but I decided to write this anyway); if that's the case, you might want to try to rebuild with the latest HEAD (I reverted the gnulib update patch today). /me thinks a bit more... I'm thinking here that this is similar to a problem we had recently, which existed when cross-compiling GDB. Basically, in this scenario, gnulib's mechanism to detect cross-compilation was poor and lead to the unneeded replacement of 'getcwd' in some systems that did have a working 'getcwd', and that was causing problems when running the cross GDB. The bug is here: https://sourceware.org/bugzilla/show_bug.cgi?id=3D23558 and the fix was to improve gnulib's machinery and make it a bit smarter when detecting cross-compilation scenarios. Thanks, --=20 Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible http://sergiodj.net/