From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 64246 invoked by alias); 12 Sep 2018 17:40:30 -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 64230 invoked by uid 89); 12 Sep 2018 17:40:29 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS autolearn=no version=3.3.2 spammy=experiencing, harmless 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:40:28 +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 CF5EB40201BD; Wed, 12 Sep 2018 17:40:26 +0000 (UTC) Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.ams2.redhat.com [10.39.146.4]) by smtp.corp.redhat.com (Postfix) with ESMTP id 704922026D76; Wed, 12 Sep 2018 17:40:23 +0000 (UTC) Subject: Re: [Buildroot] [PATCH 2/2] package/gdb: use stat() privided by the system To: Sergio Durigan Junior 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> <87ftyemyii.fsf@redhat.com> Cc: Rich Felker , Romain Naour , Thomas Petazzoni , Romain Naour , buildroot@buildroot.org, gdb-patches@sourceware.org From: Pedro Alves Message-ID: <1e098bd7-d5a4-12ad-a303-4edb6b01f91f@redhat.com> Date: Wed, 12 Sep 2018 17:40:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <87ftyemyii.fsf@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2018-09/txt/msg00367.txt.bz2 On 09/12/2018 06:11 PM, Sergio Durigan Junior wrote: > 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. gnulib provides: #1 - replacement headers for broken system headers. #2 - replacement implementations of system/libc functions, for broken systems. #3 - extra utility functions For #2, the replacement functions go by the same name as the system function, but prefixed by "rpl_". "#define foo rpl_foo" is used to provide the illusion that you're calling the original function. If all you need are replacement headers, #1 above, e.g., because you need a guarantee to have a C99-or-later-conforming stdint.h, and never call any of the functions that need to be replaced (#2), or any of the extra function (#3 above), then there's nothing of interest to link with in the generated libgnu.a. If we move the stat call elsewhere not used by the IPA, then linking the IPA with gnulib would be effectively a no-op. Until/unless someone adds some call that is resolved to some rpl_foo function that is really necessary on some port, that is. When/if that happens, we must necessarily consider whether to build a gnulib for the IPA, of course. Until then, it doesn't seem worth it to me to go through the effort in order to link in a no-op library. But if someone wants to give it a try, then please, by all means, I'd definitely be happy! It isn't impossible at all. It just seemed like the "get stat out of the way" solution would be quick enough to handle, and harmless otherwise. > > 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's just one of those things that you know after experiencing it a few times. If the linker complains about some library symbol, the first thing to look at is whether you're actually including the library in the link. Thanks, Pedro Alves