From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28211 invoked by alias); 12 Sep 2018 17:11:38 -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 28201 invoked by uid 89); 12 Sep 2018 17:11:37 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS autolearn=no version=3.3.2 spammy=Wednesday, wednesday, examining, peoples 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, 12 Sep 2018 17:11:36 +0000 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 1F26F402315B; Wed, 12 Sep 2018 17:11:34 +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 A770D2026D76; Wed, 12 Sep 2018 17:11:33 +0000 (UTC) From: Sergio Durigan Junior To: Pedro Alves Cc: Rich Felker , 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> <87lg88oolv.fsf@redhat.com> <13772de6-1197-4182-e13f-3b4f27dfa22d@redhat.com> <87d0tjopx5.fsf@redhat.com> Date: Wed, 12 Sep 2018 17:11:00 -0000 In-Reply-To: (Pedro Alves's message of "Wed, 12 Sep 2018 16:26:49 +0100") Message-ID: <87ftyemyii.fsf@redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2018-09/txt/msg00365.txt.bz2 On Wednesday, September 12 2018, Pedro Alves wrote: > On 09/11/2018 07:21 PM, Sergio Durigan Junior wrote: >> On Tuesday, September 11 2018, Pedro Alves wrote: >> >>> On 09/11/2018 01:38 AM, Sergio Durigan Junior wrote: >>> >>>> 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. >>> >>> Because the IPA doesn't link with gnulib. And the answer to that wouldn't >>> be as simple as "just link it in", because the IPA objects are supposed >>> to be compiled with -fPIC and -fvisibility=hidden. So we'd need a third >>> build of gnulib for the IPA. >> >> That explains it. It seems strange to me that we still include the >> gnulib headers when compiling IPA; I confess I just assumed IPA was >> linking with gnulib because of this. > > In order _not_ to include the gnulib headers, that would mean that we'd > be OK with going back to making sure we do any necessary portability > autoconf/#ifdefery ourselves in all of common and gdbserver code that is > used by the IPA, which doesn't sound very appealing to me. > I'd think it better / simpler maintenance-wise going forward, to work in the > direction of linking with gnulib if/when we find a need. > > The IPA has so few dependencies by design that in practice just using the > headers should be fine, with gnulib ironing-out any header-only portability > issues. It's quite likely that a port that can use the IPA won't really need > any gnu_foo replacement function. And if it does, then it should be > better to use gnulib's replacements instead of duplicating what gnulib > already does, I'd think. I guess I don't really understand what's going on behind the curtains here, then. I thought that, since IPA doesn't link with gnulib, then we shouldn't be compiling it using "... -I./../gnulib/import -Ibuild-gnulib-gdbserver/import ...", since it can be confusing for the reader to determine "oh, gnulib's header files are being included, but the library is not actually *linking* with gnulib". I understand that it'd be simpler to just build a third gnulib just for linking with IPA, but it seems like we're not going to do that, at least not right now. Anyway, this is all very unimportant and I don't want to waste people's time; I'm just trying to understand and to express the difficulty that I had while examining the logs (i.e., determining that IPA wasn't linking with gnulib, despite the inclusion of the headers). >> >>> It doesn't seem like this code that calls stat (is_regular_file?) is >>> useful for the IPA, so a quicker/simpler fix would be to simply move >>> that function out of common-utils.c into some other file that is not >>> shared with the IPA. >> >> It's not useful for IPA; it could be moved to common/filestuff.c, for >> example. > > Right. > >> But IMHO, we should probably have an explicit file just for >> IPA, because otherwise we'll forget about this restriction and re-add >> some 'stat' calls to common-utils.c. > > I'm afraid I don't understand what you mean here. This problem happened because (a) IPA doesn't link with gnulib, (b) IPA uses common-utils.c, and (c) common-utils.c calls 'stat', which, in a cross-compilation environment, gets replaced by gnulib's 'rpl_stat'. We want to solve the problem by tackling (c) and moving the 'stat' call to another file that is not used by IPA. My point is that, some time in the future, someone might not remember/be aware of this problem and reintroduce a call to 'stat' on common-utils.c, which would reintroduce this problem (assuming nothing is done on gnulib's side to fix this). I wrote the "proposal" above without completely understanding the problem. Indeed, it doesn't make sense to have a separate, IPA-specific file for common-utils.c. I guess the best approach here would be, again, to compile a separate version of gnulib for IPA. 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/