Message ID | alpine.DEB.2.20.1801191721480.329@digraph.polyomino.org.uk |
---|---|
State | Committed, archived |
Headers |
Received: (qmail 11796 invoked by alias); 19 Jan 2018 17:23:40 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <libc-alpha.sourceware.org> List-Unsubscribe: <mailto:libc-alpha-unsubscribe-##L=##H@sourceware.org> List-Subscribe: <mailto:libc-alpha-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/libc-alpha/> List-Post: <mailto:libc-alpha@sourceware.org> List-Help: <mailto:libc-alpha-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: libc-alpha-owner@sourceware.org Delivered-To: mailing list libc-alpha@sourceware.org Received: (qmail 11787 invoked by uid 89); 19 Jan 2018 17:23:39 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-24.5 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, KAM_SHORT, RCVD_IN_DNSWL_NONE, SPF_PASS, URIBL_RED autolearn=ham version=3.3.2 spammy=1.8, configs X-HELO: relay1.mentorg.com Date: Fri, 19 Jan 2018 17:23:29 +0000 From: Joseph Myers <joseph@codesourcery.com> To: Thomas Schwinge <thomas@codesourcery.com> CC: Florian Weimer <fweimer@redhat.com>, GNU C Library <libc-alpha@sourceware.org>, <bug-hurd@gnu.org>, Samuel Thibault <samuel.thibault@gnu.org>, David Michael <fedora.dm0@gmail.com> Subject: Re: Upstreaming the glibc Hurd port In-Reply-To: <87a7xaupjx.fsf@euler.schwinge.homeip.net> Message-ID: <alpine.DEB.2.20.1801191721480.329@digraph.polyomino.org.uk> References: <20180118124537.yampmyfjsbi6wvia@var.youpi.perso.aquilenet.fr> <alpine.DEB.2.20.1801181337150.2753@digraph.polyomino.org.uk> <20180118135758.xqla2yevcrjjk7si@var.youpi.perso.aquilenet.fr> <87mv1btffy.fsf@hertz.schwinge.homeip.net> <20180118151446.zqlmpbmgg4kvs2y3@var.youpi.perso.aquilenet.fr> <alpine.DEB.2.20.1801181524100.13023@digraph.polyomino.org.uk> <20180118154251.ynfyugkmog7kujom@var.youpi.perso.aquilenet.fr> <alpine.DEB.2.20.1801181642310.16200@digraph.polyomino.org.uk> <20180118165923.ymreisuzexxz4gt3@var.youpi.perso.aquilenet.fr> <alpine.DEB.2.20.1801182304260.26137@digraph.polyomino.org.uk> <20180118235924.r4z4ppvj7xlvmmfp@var.youpi.perso.aquilenet.fr> <alpine.DEB.2.20.1801190030000.26137@digraph.polyomino.org.uk> <87a7xaupjx.fsf@euler.schwinge.homeip.net> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-ClientProxiedBy: svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) |
Commit Message
Joseph Myers
Jan. 19, 2018, 5:23 p.m. UTC
On Fri, 19 Jan 2018, Thomas Schwinge wrote: > Hi Joseph! > > On Fri, 19 Jan 2018 00:34:42 +0000, Joseph Myers <joseph@codesourcery.com> wrote: > > On Fri, 19 Jan 2018, Samuel Thibault wrote: > > > > > Joseph Myers, on jeu. 18 janv. 2018 23:15:59 +0000, wrote: > > > > Thanks for the changes pushed to sthibaul/hurd-builds so far (I realise > > > > there will be more to get it into a buildable state, e.g. the actual > > > > libpthread implementation). > > > > > > What I have pushed is basically only missing the libpthread > > > implementation, so you already have an idea of the minimal set of > > > modifications to get something building (and IIRC essentially passing > > > the testsuite). > > > > I'd still like to have the libpthread implementation there (with a view to > > seeing if I can get build-many-glibcs.py working for Hurd with this branch > > Many thanks for your offer! As far as I'm aware indeed nobody from the > Hurd team has spent time on that yet. This patch adds build-many-glibcs.py support for GNU Hurd. It is intended for master, where the builds of the i686-gnu configuration would fail until sufficient support is merged to master, so completing build-many-glibcs.py coverage of all glibc ABIs and making results accurately reflect the broken state of builds for Hurd. Using sthibaul/hurd-builds branch, it reaches the glibc build, which then falls over with errors starting: In file included from mutex-init.c:19:0: ../mach/lock-intern.h: In function '__spin_lock_init': ../mach/lock-intern.h:41:13: error: 'LLL_INITIALIZER' undeclared (first use in this function) *__lock = LLL_INITIALIZER; ^~~~~~~~~~~~~~~ ../mach/lock-intern.h:41:13: note: each undeclared identifier is reported only once for each function it appears in ../mach/lock-intern.h: In function '__spin_lock': ../mach/lock-intern.h:50:3: error: implicit declaration of function 'lll_lock' [-Werror=implicit-function-declaration] lll_lock (__lock, 0); ^~~~~~~~ In file included from mutex-init.c:20:0: ../mach/lowlevellock.h: At top level: ../mach/lowlevellock.h:21:10: fatal error: mach/gnumach.h: No such file or directory #include <mach/gnumach.h> ^~~~~~~~~~~~~~~~ Could Hurd people review how this handles building for Hurd, and indicate whether the above errors indicate problems with these changes, or simply incompleteness of the build support on the sthibaul/hurd-builds branch at present? 2018-01-19 Joseph Myers <joseph@codesourcery.com> * scripts/build-many-glibcs.py (Context.add_all_configs): Add i686-gnu configurations. (Context.run_builds): Include mig, gnumach and hurd in components considered. (Context.checkout): Add mig, gnumach and hurd to components. (Context.checkout_tar): Add URL mappings for mig, gnumach and hurd. (Context.bot_cycle): Check for changes to mig, gnumach and hurd. (Config.build): Install gnumach headers, build mig and install hurd headers for 'gnu' OS. (Config.install_gnumach_headers): New function. (Config.install_hurd_headers): Likewise. (Glibc.build_glibc): Do not use /usr for 'gnu' OS. Specifiy MIG when building for 'gnu' OS.
Comments
Joseph Myers, on ven. 19 janv. 2018 17:23:29 +0000, wrote: > or simply incompleteness of the build support on the > sthibaul/hurd-builds branch at present? It's still incomplete, yes. Samuel
Incidentally, building for GNU/Linux (at least x86_64) is broken on the sthibaul/hurd-builds branch (I suspect, based on the error messages, that "t2.26/sched_param" was responsible, but didn't verify that). (I was testing to make sure my build-many-glibcs.py changes didn't affect GNU/Linux builds and so are safe to apply to master. Building for GNU/Linux is not of course a priority for the branch, but any such issues with changes to non-OS-specific code will need fixing for merging to master.)
Joseph Myers, on ven. 19 janv. 2018 17:50:19 +0000, wrote: > Incidentally, building for GNU/Linux (at least x86_64) is broken on the > sthibaul/hurd-builds branch (I suspect, based on the error messages, that > "t2.26/sched_param" was responsible, but didn't verify that). sched_param is very probably a culprit, yes. Samuel
Hello, Joseph Myers, on ven. 19 janv. 2018 17:23:29 +0000, wrote: > Could Hurd people review how this handles building for Hurd, Yes, it looks good. > and indicate whether the above errors indicate problems with these > changes, or simply incompleteness of the build support on the > sthibaul/hurd-builds branch at present? They are not related to the changes. I have pushed fix updates against them. There is just one missing thing: mig prototypes etc. are not perfect, and we thus have some nasty warnings about void * vs const void *. We'd have to use if self.os == 'gnu': cfg_cmd += ['MIG=%s' % self.tool_name('mig')] + cfg_cmd += ['--disable-werror'] for now until we fix that. Samuel
On Wed, 24 Jan 2018, Samuel Thibault wrote: > Hello, > > Joseph Myers, on ven. 19 janv. 2018 17:23:29 +0000, wrote: > > Could Hurd people review how this handles building for Hurd, > > Yes, it looks good. Thanks, I've committed it to master. > > and indicate whether the above errors indicate problems with these > > changes, or simply incompleteness of the build support on the > > sthibaul/hurd-builds branch at present? > > They are not related to the changes. I have pushed fix updates against > them. Now I see errors about missing libc-lockP.h, and "implicit declaration of function '__spin_lock_solid'", and the discarded qualifiers errors you note below. > There is just one missing thing: mig prototypes etc. are not perfect, > and we thus have some nasty warnings about void * vs const void *. We'd > have to use > > if self.os == 'gnu': > cfg_cmd += ['MIG=%s' % self.tool_name('mig')] > + cfg_cmd += ['--disable-werror'] > > for now until we fix that. A properly upstreamed port should not need --disable-werror. If workarounds are needed until there's a fixed mig release (or whatever), they could take the form of explicit casts, or CFLAGS-<file> += -Wno-error=discarded-qualifiers - disabling a particular warning being an error in a particular file is much better than globally disabling all warnings as errors. (Strictly -Wno-error=discarded-qualifiers shouldn't be used unconditionally since that warning option is new in GCC 5 and glibc supports building with GCC 4.9, but in the current state of the Hurd port I think we can ignore that in Hurd-specific Makefiles.)
Samuel Thibault, on mer. 24 janv. 2018 02:10:51 +0100, wrote: > Joseph Myers, on ven. 19 janv. 2018 17:23:29 +0000, wrote: > > and indicate whether the above errors indicate problems with these > > changes, or simply incompleteness of the build support on the > > sthibaul/hurd-builds branch at present? > > They are not related to the changes. I have pushed fix updates against > them. The next error is about inclusion of libc-lockP.h. That's where I'll have to import libpthread. Samuel
Samuel Thibault, on mer. 24 janv. 2018 02:27:26 +0100, wrote: > Samuel Thibault, on mer. 24 janv. 2018 02:10:51 +0100, wrote: > > Joseph Myers, on ven. 19 janv. 2018 17:23:29 +0000, wrote: > > > and indicate whether the above errors indicate problems with these > > > changes, or simply incompleteness of the build support on the > > > sthibaul/hurd-builds branch at present? > > > > They are not related to the changes. I have pushed fix updates against > > them. > > The next error is about inclusion of libc-lockP.h. That's where I'll > have to import libpthread. Which I have now done. I see that it now fails on missing reference to __file_exec_paths. That's indeed a new RPC which hasn't been released yet, so we'd need to use a git snapshot. Samuel
On Thu, 25 Jan 2018, Samuel Thibault wrote: > Samuel Thibault, on mer. 24 janv. 2018 02:27:26 +0100, wrote: > > Samuel Thibault, on mer. 24 janv. 2018 02:10:51 +0100, wrote: > > > Joseph Myers, on ven. 19 janv. 2018 17:23:29 +0000, wrote: > > > > and indicate whether the above errors indicate problems with these > > > > changes, or simply incompleteness of the build support on the > > > > sthibaul/hurd-builds branch at present? > > > > > > They are not related to the changes. I have pushed fix updates against > > > them. > > > > The next error is about inclusion of libc-lockP.h. That's where I'll > > have to import libpthread. > > Which I have now done. I see that it now fails on missing reference to > __file_exec_paths. That's indeed a new RPC which hasn't been released > yet, so we'd need to use a git snapshot. If a git version of Hurd (or some other component) is needed, it would be reasonable to make vcs-mainline the default version of Hurd until there's a new release. Longer-term (once Hurd is working on master) I'd hope there would be a clear (and documented) notion of minimum compile-time and run-time Hurd versions, as there is for glibc using the Linux kernel, with any features of newer versions being used only conditionally, so that the most recent releases are generally sufficient to build and use glibc for Hurd.
Regarding the libpthread / htl code, and getting it ready for inclusion in glibc master: Obviously my general coding style comments at <https://sourceware.org/ml/libc-alpha/2018-01/msg00646.html> apply equally to this code. Apart from that: * Remove htl/ChangeLog. We don't have subdirectory ChangeLogs now. Everything goes in the top-level ChangeLog, with older ChangeLogs (that have actual ChangeLog content) being in the ChangeLog.old/ directory. When importing files / patches previously maintained elsewhere, I *do* think the ChangeLog header for those patches should name all authors who contributed to them (which may make for a long header with lots of authors listed). (If the GNU Coding Standards change to stop requiring ChangeLog format and we decide to stop using it, we'll still need some convention for how to credit multi-author patches.) * Remove htl/tests/.cvsignore. * Support for building htl outside the glibc source tree (or with older glibc versions) should not be included. * Files in htl/sysdeps should be moved into appropriate locations in the main sysdeps tree, just as was done with nptl/sysdeps when nptl ceased to be an add-on. * You seem to have some custom system for building tests in htl/tests. Tests should be built and run using the normal glibc testsuite machinery (and should use <support/test-driver.c>). * You have four installed non-bits/ API headers: pthread.h pthread/pthread.h pthread/pthreadtypes.h semaphore.h. NPTL has just pthread.h and semaphore.h. Do you really need pthread/pthread.h and pthread/pthreadtypes.h as installed public API headers? I'd expect the same two API headers as NPTL has. * The bits/ convention is for headers that are (a) installed, (b) only for use by other installed headers, not for direct inclusion by users (and sometimes have #error conditionals to guard against direct inclusion). Within that convention, there's a newer bits/types/ convention for headers defining a single type, which is intended as a replacement for the older __need_* convention. Now, this brings up three points regarding the htl code (and possibly other pieces in the Hurd port). (i) You still have some headers that define or use __need_*; those should be changed to use bits/types/ headers (__need_* has generally been eliminated from glibc, except where it's defined before including *GCC* headers, not glibc ones). (ii) Some of the bits/ headers in htl look like they are just defining a single type, so should actually be bits/types/ headers named according to the new convention. (iii) bits/memory.h and bits/pt-atomic.h don't appear to be installed headers, meaning they should not have bits/ names. Actually, uses of those headers should probably be changed to use glibc's existing atomic.h interfaces, and those htl-specific headers removed - if for some reason the existing atomic.h interfaces are insufficient, maybe those interfaces need to be extended. The following would be desirable cleanups, but maybe for after the code is in master: * I'd expect that NPTL tests (and likewise HTL tests) are largely tests of POSIX (or GNU extension) threading functionality, not of features specific to one threading implementation. Thus, they should as far as possible be shared between the different threading implementations. I don't know the best directory arrangements for achieving that. * Hopefully C11 threads support will be added for 2.28 (didn't get reviewed in time for 2.27). The existing patches put it in the nptl/ directory, but again, to the extent that it actually builds on generic pthreads functionality, the code and its tests should be shared as much as possible between NPTL and HTL. * Likewise for the pthread.h and semaphore.h API headers - only parts genuinely specific to a given implementation should be split out into implementation-specific bits/ headers. (Indeed, the NPTL semaphore.h is already in sysdeps/pthread/ not an NPTL-specific directory - do you really need a different one for HTL?)
Joseph Myers, on jeu. 25 janv. 2018 16:12:48 +0000, wrote:
> do you really need [foo]
Assume no :)
I just imported the source as it is, containing everything that was
previously needed to make it buildable both within the hurd repository
and the glibc repository.
Thanks for listing the issues, though :)
Samuel
Hello, Thanks a lot for the feedback on what needs to be done. It was a busy week-end :) We should be almost there, I believe I had addressed in sthibaul/hurd-builds all requirements except a few remaining bits: - Two patches pending comments on libc-alpha: [PATCH] hurd: Initialize TLS and libpthread before signal thread start [PATCH] hurd: Fix early rtld access to errno - plugging the htl tests to the glibc test infrastructure. - Fixing GNU Coding Style, notably first line of files. - Fixing the date in sysdeps/mach/hurd/bits/posix_opt.h. Samuel
On Sun, Mar 18, 2018 at 9:51 PM, Samuel Thibault <samuel.thibault@gnu.org> wrote: > Hello, > > Thanks a lot for the feedback on what needs to be done. It was a busy > week-end :) > > We should be almost there, I believe I had addressed in > sthibaul/hurd-builds all requirements except a few remaining bits: Is it still expected that glibc trunk cannot be built in the --host=i686-gnu configuration? I am getting In file included from ../include/link.h:52:0, from ../include/dlfcn.h:4, from ../sysdeps/generic/ldsodefs.h:32, from ../sysdeps/i386/ldsodefs.h:39, from ../sysdeps/gnu/ldsodefs.h:46, from setup-thread.c:22: ../sysdeps/mach/libc-lock.h:227:11: fatal error: libc-lockP.h: No such file or directory # include <libc-lockP.h> ^~~~~~~~~~~~~~ compilation terminated. (I would like to suggest that getting "scripts/build-many-glibcs.py $workdir compilers i686-gnu" to succeed, and "scripts/build-many-glibcs.py $workdir glibcs i686-gnu" to fail only in the testsuite phase, when $workdir/src/glibc contains a trunk checkout, should be top priority -- once you get to that point, people working on cross-cutting changes (like me) can ensure that they haven't made the state of the Hurd port worse.) zw
Zack Weinberg, on lun. 19 mars 2018 11:36:18 -0400, wrote: > On Sun, Mar 18, 2018 at 9:51 PM, Samuel Thibault > <samuel.thibault@gnu.org> wrote: > > Hello, > > > > Thanks a lot for the feedback on what needs to be done. It was a busy > > week-end :) > > > > We should be almost there, I believe I had addressed in > > sthibaul/hurd-builds all requirements except a few remaining bits: > > Is it still expected that glibc trunk cannot be built in the > --host=i686-gnu configuration? I am getting Are you using the sthibaul/hurd-builds branch? There are still things missing in master, notably the htl/ directories. > (I would like to suggest that getting "scripts/build-many-glibcs.py > $workdir compilers i686-gnu" to succeed, It does work on my system with the sthibaul/hurd-builds branch. > when $workdir/src/glibc contains a trunk checkout, should be top > priority Sure, that's precisely my goal. I'm just checking for things that might look odd in the sthibaul/hurd-builds branch before I push them to master. Samuel
On Mon, Mar 19, 2018 at 11:46 AM, Samuel Thibault <samuel.thibault@gnu.org> wrote: > Zack Weinberg, on lun. 19 mars 2018 11:36:18 -0400, wrote: >> On Sun, Mar 18, 2018 at 9:51 PM, Samuel Thibault >> <samuel.thibault@gnu.org> wrote: >> > Hello, >> > >> > Thanks a lot for the feedback on what needs to be done. It was a busy >> > week-end :) >> > >> > We should be almost there, I believe I had addressed in >> > sthibaul/hurd-builds all requirements except a few remaining bits: >> >> Is it still expected that glibc trunk cannot be built in the >> --host=i686-gnu configuration? I am getting > > Are you using the sthibaul/hurd-builds branch? No, that's what I meant by "glibc trunk". > There are still things missing in master, notably the htl/ > directories. Oh, OK. No hurry. zw
Zack Weinberg, on lun. 19 mars 2018 11:54:21 -0400, wrote: > On Mon, Mar 19, 2018 at 11:46 AM, Samuel Thibault > <samuel.thibault@gnu.org> wrote: > > Zack Weinberg, on lun. 19 mars 2018 11:36:18 -0400, wrote: > >> On Sun, Mar 18, 2018 at 9:51 PM, Samuel Thibault > >> <samuel.thibault@gnu.org> wrote: > >> > Hello, > >> > > >> > Thanks a lot for the feedback on what needs to be done. It was a busy > >> > week-end :) > >> > > >> > We should be almost there, I believe I had addressed in > >> > sthibaul/hurd-builds all requirements except a few remaining bits: > >> > >> Is it still expected that glibc trunk cannot be built in the > >> --host=i686-gnu configuration? I am getting > > > > Are you using the sthibaul/hurd-builds branch? > > No, that's what I meant by "glibc trunk". Ok, sorry, I missed the "trunk" workd :) Samuel
Hello Samuel, 19.03.2018 02:51 Samuel Thibault <samuel.thibault@gnu.org> wrote: > > Hello, > > Thanks a lot for the feedback on what needs to be done. It was a busy > week-end :) I appreciate your work. :-) Sorry for a kinda off-topic but could you please visit the Patchwork site [1] and mark your committed patches as committed, or ask someone to do it for you? I'm asking in public because there are lots of patches from other people as well, also this makes a chance for someone to respond in case if I'm too overzealous. Thank you. Regards, Rafal [1] https://patchwork.sourceware.org/project/glibc/list/
Hello, Rafal Luzynski, on mar. 27 mars 2018 01:13:23 +0200, wrote: > I appreciate your work. :-) Sorry for a kinda off-topic but could you > please visit the Patchwork site [1] and mark your committed patches > as committed, or ask someone to do it for you? Oh, I didn't know about it. Is there a way to make them marked as commited right from the mail subject, for future commits? Samuel
Rafal Luzynski, on mar. 27 mars 2018 01:13:23 +0200, wrote: > 19.03.2018 02:51 Samuel Thibault <samuel.thibault@gnu.org> wrote: > > Thanks a lot for the feedback on what needs to be done. It was a busy > > week-end :) > > I appreciate your work. :-) Sorry for a kinda off-topic but could you > please visit the Patchwork site [1] and mark your committed patches > as committed, or ask someone to do it for you? It seems I can't mark patches submitted by other people, perhaps I just need to be added to the "Maintainers" list? Samuel
27.03.2018 09:45 Samuel Thibault <samuel.thibault@gnu.org> wrote: > [...] > Oh, I didn't know about it. Is there a way to make them marked as > commited right from the mail subject, for future commits? I don't know. Any hints, anybody? 27.03.2018 11:00 Samuel Thibault <samuel.thibault@gnu.org> wrote: > [...] > It seems I can't mark patches submitted by other people, perhaps I just > need to be added to the "Maintainers" list? No, I wouldn't ask you to mark patches by other people, if you mark your own patches that would be a great cleaning work already. When I mentioned other people I meant that other people should do the same with their own patches, so that's a general message, not just for you. Regards, Rafal
Rafal Luzynski, on mar. 27 mars 2018 12:40:27 +0200, wrote: > 27.03.2018 11:00 Samuel Thibault <samuel.thibault@gnu.org> wrote: > > [...] > > It seems I can't mark patches submitted by other people, perhaps I just > > need to be added to the "Maintainers" list? > > No, I wouldn't ask you to mark patches by other people, if you mark > your own patches that would be a great cleaning work already. Just to be sure: I meant patches submitted by others which I have commited myself to glibc. Samuel
27.03.2018 12:43 Samuel Thibault <samuel.thibault@gnu.org> wrote: > Rafal Luzynski, on mar. 27 mars 2018 12:40:27 +0200, wrote: > > 27.03.2018 11:00 Samuel Thibault <samuel.thibault@gnu.org> wrote: > > > [...] > > > It seems I can't mark patches submitted by other people, perhaps I just > > > need to be added to the "Maintainers" list? > > > > No, I wouldn't ask you to mark patches by other people, if you mark > > your own patches that would be a great cleaning work already. > > Just to be sure: I meant patches submitted by others which I have > commited myself to glibc. That's only more confusing for me. I am a relatively new maintainer here, this explains why it is so easy for me to put my attention on the things I learned not so long ago. Regarding your questions we need some feedback from more experienced maintainers, I am curious as well. Regards, Rafal
Samuel Thibault <samuel.thibault@gnu.org> writes: > Rafal Luzynski, on mar. 27 mars 2018 01:13:23 +0200, wrote: >> 19.03.2018 02:51 Samuel Thibault <samuel.thibault@gnu.org> wrote: >> > Thanks a lot for the feedback on what needs to be done. It was a busy >> > week-end :) >> >> I appreciate your work. :-) Sorry for a kinda off-topic but could you >> please visit the Patchwork site [1] and mark your committed patches >> as committed, or ask someone to do it for you? > > It seems I can't mark patches submitted by other people, perhaps I just > need to be added to the "Maintainers" list? Indeed. Carlos and Siddhesh, could you help Samuel? For the record: Carlos and Siddhesh are the maintainers of our Patchwork instance. https://sourceware.org/glibc/wiki/MAINTAINERS#Maintainers_for_the_patchwork_instance I can't put your account in the maintainers list, but I can change the status of the patches. Are these all the patches pending an update there? https://patchwork.sourceware.org/project/glibc/list/?submitter=384
On 03/27/2018 09:46 AM, Tulio Magno Quites Machado Filho wrote: > Samuel Thibault <samuel.thibault@gnu.org> writes: > >> Rafal Luzynski, on mar. 27 mars 2018 01:13:23 +0200, wrote: >>> 19.03.2018 02:51 Samuel Thibault <samuel.thibault@gnu.org> wrote: >>>> Thanks a lot for the feedback on what needs to be done. It was a busy >>>> week-end :) >>> >>> I appreciate your work. :-) Sorry for a kinda off-topic but could you >>> please visit the Patchwork site [1] and mark your committed patches >>> as committed, or ask someone to do it for you? >> >> It seems I can't mark patches submitted by other people, perhaps I just >> need to be added to the "Maintainers" list? > > Indeed. > > Carlos and Siddhesh, could you help Samuel? Fixed. I added Samuel to the maintainers list. > For the record: Carlos and Siddhesh are the maintainers of our Patchwork > instance. > https://sourceware.org/glibc/wiki/MAINTAINERS#Maintainers_for_the_patchwork_instance > > I can't put your account in the maintainers list, but I can change the status > of the patches. > Are these all the patches pending an update there? > https://patchwork.sourceware.org/project/glibc/list/?submitter=384
Hello, So, after various coding style fixes etc. I eventually pushed htl. This means that build-glibcs i686-gnu now builds fine. Among the remaining TODOs, there are - making testsuite pass - fixing the generated errno file thing - sharing tests between nptl and htl - sharing pthread.h - C11 threads Concerning the testsuite, perhaps we could xfail the existing issues so that build-glibcs i686-gnu succeeds? Currently there are: - header standard conformity issues: These will be hard to fix. - elf/check-localplt: There will always be PLTs to libhurd/machuser.so anyway. - elf/check-execstack: We have nested functions which make the stack executable indeed. - check-abi-libmachuser, check-abi-libhurduser: These actually depend on .defs files in gnumach and hurd, so we can't really define ABI files. Samuel
On 04/02/2018 02:10 AM, Samuel Thibault wrote: > - elf/check-execstack: We have nested functions which make the stack > executable indeed. I looked at the Hurd situation last month. Hurd is always read-implies-exec, I think. So there is no need to make the stacks executable, it does not have any observable effect on execution and therefore cannot be tested. Thanks, Florian
Florian Weimer, on lun. 02 avril 2018 09:51:00 +0200, wrote: > On 04/02/2018 02:10 AM, Samuel Thibault wrote: > > - elf/check-execstack: We have nested functions which make the stack > > executable indeed. > > I looked at the Hurd situation last month. Hurd is always > read-implies-exec, I think. Nobody has implemented NX in gnumach yet, but that doesn't mean nobody will. Samuel
On Mon, 2 Apr 2018, Samuel Thibault wrote: > - header standard conformity issues: These will be hard to fix. What are the issues here? > - elf/check-localplt: There will always be PLTs to libhurd/machuser.so > anyway. If a library has *local* PLT entries - PLT entries for within-library calls to other functions in that shared library - that are hard to fix to use hidden aliases, it's expected that the localplt.data files will list those as expected (with a "?" if the PLT entry may or may not be present depending on compiler version etc., as is the case for some configurations where functions get exported from both libgcc and glibc). > - elf/check-execstack: We have nested functions which make the stack > executable indeed. That's pointers to nested functions involving creation of trampolines? Do those nested functions actually improve the code or would it be cleaner (have cleaner internal interfaces etc.) without them? Do all libraries have these or only some? > - check-abi-libmachuser, check-abi-libhurduser: These actually depend on > .defs files in gnumach and hurd, so we can't really define ABI files. Depend in what way? Are you saying they export different symbols depending on the versions of gnumach and hurd glibc is built with? How are symbol versions for such extra symbols determined - based on gnumach and hurd versions instead of glibc versions? It's clearly desirable to be able to make sure that old symbol versions don't change. But if the contents of those versions are determined by gnumach and hurd, maybe those packages need to install ABI baselines for the glibc tests (or something like that). The nearest analogue I see in glibc for systems using the Linux kernel (without more information on how the gnumach/hurd dependency works) is the syscall lists - where we have a list in glibc of all possible syscall names (sysdeps/unix/sysv/linux/syscall-names.list), and a test will fail if the kernel has additional syscalls and is not newer than the version listed in that list (so using a different kernel version does not result in test failures, but the test is fully effective if the listed kernel version or an older kernel version is used).
On Mon, 2 Apr 2018, Samuel Thibault wrote: > This means that build-glibcs i686-gnu now builds fine. Among the > remaining TODOs, there are Thanks! I'd add: the "requires out-of-tree patches" statement in README needs to be removed, and a NEWS entry is needed. Will you be able to provide full execution test results for the testsuite on the per-release wiki pages for 2.28 and later releases, during each release freeze period?
Hello, Joseph Myers, on lun. 02 avril 2018 14:22:28 +0000, wrote: > On Mon, 2 Apr 2018, Samuel Thibault wrote: > > > This means that build-glibcs i686-gnu now builds fine. Among the > > remaining TODOs, there are > > Thanks! I'd add: the "requires out-of-tree patches" statement in README > needs to be removed, Oh, I was unaware of that mention. > and a NEWS entry is needed. Right :) > Will you be able to provide full execution test results for the > testsuite on the per-release wiki pages for 2.28 and later releases, > during each release freeze period? Now that it does build and run quite fine, sure! :) Samuel
Joseph Myers, on lun. 02 avril 2018 14:17:38 +0000, wrote: > On Mon, 2 Apr 2018, Samuel Thibault wrote: > > > - header standard conformity issues: These will be hard to fix. > > What are the issues here? Some of these are small, like ./bits/types/sigevent_t.h's sigev_notify_attributes not being pthread_attr_t* Others need some work, like the missing SA_SIGINFO, for which we have patches which need polishing and committing. Others need implementing, like SA_NOCLDWAIT. Others just need defining, like IUCLC, IXANY, etc. There are a few remaining namespace issues due to missing __ marking or spurious #includes. So those, we can fix them. Others really pose problem, like ./sysdeps/mach/hurd/bits/fcntl.h's l_type/l_whence being int instead of short. There is also sys/un.h which defines a sun_len field, which IIRC is to be expected on BSD systems, but not defined in Posix? Also, ioctl takes (int, unsigned long int, ...) but ./conform/XPG42/stropts.h/conform.out wants (int, int, ...)? > > - elf/check-localplt: There will always be PLTs to libhurd/machuser.so > > anyway. > > If a library has *local* PLT entries - Ah. I got confused by the presence of __vm_allocate which is an RPC, but we actually have a non-RPC version inside libc.so itself. There are a hundred of them mostly in libc.so, ld.so, libpthread.so > PLT entries for within-library calls to other functions in that shared > library - that are hard to fix to use hidden aliases, it's expected > that the localplt.data files will list those as expected Ok. > > - elf/check-execstack: We have nested functions which make the stack > > executable indeed. > > That's pointers to nested functions involving creation of trampolines? Yes. > Do those nested functions actually improve the code Yes. There are notably callbacks whose parameters don't permit to get the context parameters etc. > Do all libraries have these or only some? Only libc.so, ld.so and libpthread.so have them. > > - check-abi-libmachuser, check-abi-libhurduser: These actually depend on > > .defs files in gnumach and hurd, so we can't really define ABI files. > > Depend in what way? Are you saying they export different symbols > depending on the versions of gnumach and hurd glibc is built with? That is it, yes. > How are symbol versions for such extra symbols determined - based on > gnumach and hurd versions instead of glibc versions? That was not actually settled, but I guess it should be gnumach and hurd versions. > maybe those packages need to install ABI baselines for the glibc tests > (or something like that). Indeed. Samuel
On Mon, Apr 2, 2018 at 7:47 AM, Samuel Thibault <samuel.thibault@gnu.org> wrote: > Hello, > > Joseph Myers, on lun. 02 avril 2018 14:22:28 +0000, wrote: >> On Mon, 2 Apr 2018, Samuel Thibault wrote: >> >> > This means that build-glibcs i686-gnu now builds fine. Among the >> > remaining TODOs, there are >> >> Thanks! I'd add: the "requires out-of-tree patches" statement in README >> needs to be removed, > > Oh, I was unaware of that mention. > > mig master branch failed to build on Fedora 27: gcc -g -O2 -o migcom error.o global.o header.o lexxer.o migcom.o parser.o routine.o server.o statement.o string.o type.o user.o utils.o vprint.o /usr/local/bin/ld: lexxer.o: in function `yylex': /export/gnu/import/git/toolchain/build/compilers/i686-gnu/mig/lexxer.c:1834: undefined reference to `yywrap' collect2: error: ld returned 1 exit status make[3]: *** [Makefile:495: migcom] Error 1 H.J.
Samuel Thibault, on lun. 02 avril 2018 17:50:17 +0200, wrote: > There are a few remaining namespace issues due to missing __ marking or > spurious #includes. One issue is with struct sched_param. The __sched_param definition was removed in glibc while htl's pthread_attr uses it. For now I just made struct___pthread_attr.h include <sched.h> but that brings things unwanted for <sys/types.h> (which is supposed to pull pthread_attr). So I guess we should revert to defining __sched_param? Samuel
H.J. Lu, on lun. 02 avril 2018 09:01:30 -0700, wrote: > On Mon, Apr 2, 2018 at 7:47 AM, Samuel Thibault <samuel.thibault@gnu.org> wrote: > > Hello, > > > > Joseph Myers, on lun. 02 avril 2018 14:22:28 +0000, wrote: > >> On Mon, 2 Apr 2018, Samuel Thibault wrote: > >> > >> > This means that build-glibcs i686-gnu now builds fine. Among the > >> > remaining TODOs, there are > >> > >> Thanks! I'd add: the "requires out-of-tree patches" statement in README > >> needs to be removed, > > > > Oh, I was unaware of that mention. > > mig master branch failed to build on Fedora 27: > > gcc -g -O2 -o migcom error.o global.o header.o lexxer.o migcom.o > parser.o routine.o server.o statement.o string.o type.o user.o utils.o > vprint.o > /usr/local/bin/ld: lexxer.o: in function `yylex': > /export/gnu/import/git/toolchain/build/compilers/i686-gnu/mig/lexxer.c:1834: > undefined reference to `yywrap' Could you post config.log? configure is supposed to detect this: checking lex library... -lfl Samuel
On Mon, Apr 2, 2018 at 9:16 AM, Samuel Thibault <samuel.thibault@gnu.org> wrote: > H.J. Lu, on lun. 02 avril 2018 09:01:30 -0700, wrote: >> On Mon, Apr 2, 2018 at 7:47 AM, Samuel Thibault <samuel.thibault@gnu.org> wrote: >> > Hello, >> > >> > Joseph Myers, on lun. 02 avril 2018 14:22:28 +0000, wrote: >> >> On Mon, 2 Apr 2018, Samuel Thibault wrote: >> >> >> >> > This means that build-glibcs i686-gnu now builds fine. Among the >> >> > remaining TODOs, there are >> >> >> >> Thanks! I'd add: the "requires out-of-tree patches" statement in README >> >> needs to be removed, >> > >> > Oh, I was unaware of that mention. >> >> mig master branch failed to build on Fedora 27: >> >> gcc -g -O2 -o migcom error.o global.o header.o lexxer.o migcom.o >> parser.o routine.o server.o statement.o string.o type.o user.o utils.o >> vprint.o >> /usr/local/bin/ld: lexxer.o: in function `yylex': >> /export/gnu/import/git/toolchain/build/compilers/i686-gnu/mig/lexxer.c:1834: >> undefined reference to `yywrap' > > Could you post config.log? configure is supposed to detect this: > > checking lex library... -lfl > checking lex library... none needed
H.J. Lu, on lun. 02 avril 2018 10:06:14 -0700, wrote: > On Mon, Apr 2, 2018 at 9:16 AM, Samuel Thibault <samuel.thibault@gnu.org> wrote: > > H.J. Lu, on lun. 02 avril 2018 09:01:30 -0700, wrote: > >> On Mon, Apr 2, 2018 at 7:47 AM, Samuel Thibault <samuel.thibault@gnu.org> wrote: > >> > Hello, > >> > > >> > Joseph Myers, on lun. 02 avril 2018 14:22:28 +0000, wrote: > >> >> On Mon, 2 Apr 2018, Samuel Thibault wrote: > >> >> > >> >> > This means that build-glibcs i686-gnu now builds fine. Among the > >> >> > remaining TODOs, there are > >> >> > >> >> Thanks! I'd add: the "requires out-of-tree patches" statement in README > >> >> needs to be removed, > >> > > >> > Oh, I was unaware of that mention. > >> > >> mig master branch failed to build on Fedora 27: > >> > >> gcc -g -O2 -o migcom error.o global.o header.o lexxer.o migcom.o > >> parser.o routine.o server.o statement.o string.o type.o user.o utils.o > >> vprint.o > >> /usr/local/bin/ld: lexxer.o: in function `yylex': > >> /export/gnu/import/git/toolchain/build/compilers/i686-gnu/mig/lexxer.c:1834: > >> undefined reference to `yywrap' > > > > Could you post config.log? configure is supposed to detect this: > > > > checking lex library... -lfl > > checking lex library... none needed Please really config.log, not only the configure output. Samuel
On Mon, Apr 2, 2018 at 10:15 AM, Samuel Thibault <samuel.thibault@gnu.org> wrote: > H.J. Lu, on lun. 02 avril 2018 10:06:14 -0700, wrote: >> On Mon, Apr 2, 2018 at 9:16 AM, Samuel Thibault <samuel.thibault@gnu.org> wrote: >> > H.J. Lu, on lun. 02 avril 2018 09:01:30 -0700, wrote: >> >> On Mon, Apr 2, 2018 at 7:47 AM, Samuel Thibault <samuel.thibault@gnu.org> wrote: >> >> > Hello, >> >> > >> >> > Joseph Myers, on lun. 02 avril 2018 14:22:28 +0000, wrote: >> >> >> On Mon, 2 Apr 2018, Samuel Thibault wrote: >> >> >> >> >> >> > This means that build-glibcs i686-gnu now builds fine. Among the >> >> >> > remaining TODOs, there are >> >> >> >> >> >> Thanks! I'd add: the "requires out-of-tree patches" statement in README >> >> >> needs to be removed, >> >> > >> >> > Oh, I was unaware of that mention. >> >> >> >> mig master branch failed to build on Fedora 27: >> >> >> >> gcc -g -O2 -o migcom error.o global.o header.o lexxer.o migcom.o >> >> parser.o routine.o server.o statement.o string.o type.o user.o utils.o >> >> vprint.o >> >> /usr/local/bin/ld: lexxer.o: in function `yylex': >> >> /export/gnu/import/git/toolchain/build/compilers/i686-gnu/mig/lexxer.c:1834: >> >> undefined reference to `yywrap' >> > >> > Could you post config.log? configure is supposed to detect this: >> > >> > checking lex library... -lfl >> >> checking lex library... none needed > > Please really config.log, not only the configure output. > configure:4096: checking lex library configure:4110: gcc -o conftest -g -O2 conftest.c >&5 /usr/local/bin/ld: /tmp/ccDAnO2r.o: in function `input': /export/gnu/import/git/toolchain/build/compilers/i686-gnu/mig/lex.yy.c:1185: undefined reference to `yywrap' /usr/local/bin/ld: /tmp/ccDAnO2r.o: in function `yylex': /export/gnu/import/git/toolchain/build/compilers/i686-gnu/mig/lex.yy.c:879: undefined reference to `yywrap' /usr/local/bin/ld: /tmp/ccDAnO2r.o: in function `main': /export/gnu/import/git/toolchain/build/compilers/i686-gnu/mig/conftest.l:18: undefined reference to `yywrap' collect2: error: ld returned 1 exit status configure:4110: $? = 1 .... configure:4460: result: no ... configure: exit 0
H.J. Lu, on lun. 02 avril 2018 10:22:31 -0700, wrote: > On Mon, Apr 2, 2018 at 10:15 AM, Samuel Thibault > <samuel.thibault@gnu.org> wrote: > > H.J. Lu, on lun. 02 avril 2018 10:06:14 -0700, wrote: > >> On Mon, Apr 2, 2018 at 9:16 AM, Samuel Thibault <samuel.thibault@gnu.org> wrote: > >> > H.J. Lu, on lun. 02 avril 2018 09:01:30 -0700, wrote: > >> >> On Mon, Apr 2, 2018 at 7:47 AM, Samuel Thibault <samuel.thibault@gnu.org> wrote: > >> >> > Hello, > >> >> > > >> >> > Joseph Myers, on lun. 02 avril 2018 14:22:28 +0000, wrote: > >> >> >> On Mon, 2 Apr 2018, Samuel Thibault wrote: > >> >> >> > >> >> >> > This means that build-glibcs i686-gnu now builds fine. Among the > >> >> >> > remaining TODOs, there are > >> >> >> > >> >> >> Thanks! I'd add: the "requires out-of-tree patches" statement in README > >> >> >> needs to be removed, > >> >> > > >> >> > Oh, I was unaware of that mention. > >> >> > >> >> mig master branch failed to build on Fedora 27: > >> >> > >> >> gcc -g -O2 -o migcom error.o global.o header.o lexxer.o migcom.o > >> >> parser.o routine.o server.o statement.o string.o type.o user.o utils.o > >> >> vprint.o > >> >> /usr/local/bin/ld: lexxer.o: in function `yylex': > >> >> /export/gnu/import/git/toolchain/build/compilers/i686-gnu/mig/lexxer.c:1834: > >> >> undefined reference to `yywrap' > >> > > >> > Could you post config.log? configure is supposed to detect this: > >> > > >> > checking lex library... -lfl > >> > >> checking lex library... none needed > > > > Please really config.log, not only the configure output. > > > > configure:4096: checking lex library > configure:4110: gcc -o conftest -g -O2 conftest.c >&5 > /usr/local/bin/ld: /tmp/ccDAnO2r.o: in function `input': > /export/gnu/import/git/toolchain/build/compilers/i686-gnu/mig/lex.yy.c:1185: > undefined reference to `yywrap' > /usr/local/bin/ld: /tmp/ccDAnO2r.o: in function `yylex': > /export/gnu/import/git/toolchain/build/compilers/i686-gnu/mig/lex.yy.c:879: > undefined reference to `yywrap' > /usr/local/bin/ld: /tmp/ccDAnO2r.o: in function `main': > /export/gnu/import/git/toolchain/build/compilers/i686-gnu/mig/conftest.l:18: > undefined reference to `yywrap' > collect2: error: ld returned 1 exit status > configure:4110: $? = 1 > .... > configure:4460: result: no Please really post config.log (or send it privately). "result: no" here is not related to "checking lex library". Samuel
Samuel Thibault, on lun. 02 avril 2018 19:35:11 +0200, wrote: > > configure:4096: checking lex library > > configure:4110: gcc -o conftest -g -O2 conftest.c >&5 > > /usr/local/bin/ld: /tmp/ccDAnO2r.o: in function `input': > > /export/gnu/import/git/toolchain/build/compilers/i686-gnu/mig/lex.yy.c:1185: > > undefined reference to `yywrap' > > /usr/local/bin/ld: /tmp/ccDAnO2r.o: in function `yylex': > > /export/gnu/import/git/toolchain/build/compilers/i686-gnu/mig/lex.yy.c:879: > > undefined reference to `yywrap' > > /usr/local/bin/ld: /tmp/ccDAnO2r.o: in function `main': > > /export/gnu/import/git/toolchain/build/compilers/i686-gnu/mig/conftest.l:18: > > undefined reference to `yywrap' > > collect2: error: ld returned 1 exit status > > configure:4110: $? = 1 > > .... > > configure:4460: result: no > > Please really post config.log (or send it privately). "result: no" here > is not related to "checking lex library". I guess you don't have libfl-devel on your system, and apparently autoconf's programs.m4 doesn't actually handle that case. Samuel
On Mon, 2 Apr 2018, Samuel Thibault wrote: > Others really pose problem, like ./sysdeps/mach/hurd/bits/fcntl.h's > l_type/l_whence being int instead of short. Where something is problematic to fix, because a fix would break the ABI or needs some external feature, there is an xfail mechanism internal to the conform tests. It involves a bug being filed in Bugzilla for the issue in question, an addition to conformtest-xfail-conds (conditional on ifeq ($(subdir),conform)) in an appropriate sysdeps Makefile, with a comment referencing the bug, and xfail[cond]- on the relevant expectation in the relevant -data file, again with a comment referencing the bug. For example: // Bug 17786: st_dev has wrong type. xfail[mips-o32-linux]-element {struct stat} dev_t st_dev Before doing any such XFAILing, you should check that the expectation is actually backed up by the relevant standard and that a fix really does need an ABI change or a new feature. Also, this XFAIL mechanism can only be used for positive expectations that are failing - it can't be used for cases where the header violates the expected namespace. > There is also sys/un.h which defines a sun_len field, which IIRC is to > be expected on BSD systems, but not defined in Posix? Well, in fact POSIX reserves sun_* for sys/un.h (note the reservations are in a separate part of the standard from the main definitions of header contents), so there's a bug in the expectations not allowing for it. This illustrates the need for checking such failures against the standards to see where the bug is. > Also, ioctl takes (int, unsigned long int, ...) but > ./conform/XPG42/stropts.h/conform.out wants (int, int, ...)? That's already generically XFAILed with reference to bug 14362. > > Do those nested functions actually improve the code > > Yes. There are notably callbacks whose parameters don't permit to get > the context parameters etc. > > > Do all libraries have these or only some? > > Only libc.so, ld.so and libpthread.so have them. Then maybe some mechanism is needed for sysdeps Makefiles to define libraries expected to have executable stacks.
On Mon, 2 Apr 2018, Samuel Thibault wrote: > Samuel Thibault, on lun. 02 avril 2018 17:50:17 +0200, wrote: > > There are a few remaining namespace issues due to missing __ marking or > > spurious #includes. > > One issue is with struct sched_param. The __sched_param definition > was removed in glibc while htl's pthread_attr uses it. For now I just > made struct___pthread_attr.h include <sched.h> but that brings things > unwanted for <sys/types.h> (which is supposed to pull pthread_attr). > > So I guess we should revert to defining __sched_param? If you need, on Hurd, in installed headers, a type "struct __sched_param", that would most naturally go in a Hurd-specific bits/types/struct___sched_param.h. If that's not appropriate, please explain the issue in more detail. Anything restoring the old __need_* mechanism for any glibc-internal definitions is not appropriate (struct __sched_param was removed as part of removing __need_*).
On Mon, 2 Apr 2018, Samuel Thibault wrote: > This means that build-glibcs i686-gnu now builds fine. Among the > remaining TODOs, there are If you use mainline GCC, however, it fails: ../sysdeps/mach/hurd/if_index.c: In function '__if_nametoindex': ../sysdeps/mach/hurd/if_index.c:40:3: error: 'strncpy' specified bound 16 equals destination size [-Werror=stringop-truncation] strncpy (ifr.ifr_name, ifname, IFNAMSIZ); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Joseph Myers, on mar. 03 avril 2018 15:45:13 +0000, wrote: > On Mon, 2 Apr 2018, Samuel Thibault wrote: > > > This means that build-glibcs i686-gnu now builds fine. Among the > > remaining TODOs, there are > > If you use mainline GCC, however, it fails: > > ../sysdeps/mach/hurd/if_index.c: In function '__if_nametoindex': > ../sysdeps/mach/hurd/if_index.c:40:3: error: 'strncpy' specified bound 16 equals destination size [-Werror=stringop-truncation] > strncpy (ifr.ifr_name, ifname, IFNAMSIZ); > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Oh, a real bug indeed :) Samuel
The build for i686-gnu also fails using GCC 6 branch with build-many-glibcs.py: hurdsig.c: In function 'interrupted_reply_port_location.isra.1': hurdsig.c:250:39: error: 'portloc' may be used uninitialized in this function [-Werror=maybe-uninitialized] *(volatile mach_port_t *) portloc = *portloc; ^~~~~~~~ I haven't investigated whether this warning is valid, or whether it's bogus (in which case we don't add initializations just to fix warnings, but may used DIAG_*_NEEDS_COMMENT with appropriate explanations of what warning appears and why it is bogus).
Joseph Myers, on mar. 03 avril 2018 21:48:32 +0000, wrote: > The build for i686-gnu also fails using GCC 6 branch with > build-many-glibcs.py: > > hurdsig.c: In function 'interrupted_reply_port_location.isra.1': > hurdsig.c:250:39: error: 'portloc' may be used uninitialized in this function [-Werror=maybe-uninitialized] > *(volatile mach_port_t *) portloc = *portloc; > ^~~~~~~~ > > I haven't investigated whether this warning is valid, or whether it's > bogus Well, it's completely bogus: portloc is initialized just above. I don't understand why it wouldn't see that. Samuel
On Tue, Apr 3, 2018 at 5:58 PM, Samuel Thibault <samuel.thibault@gnu.org> wrote: > Joseph Myers, on mar. 03 avril 2018 21:48:32 +0000, wrote: >> The build for i686-gnu also fails using GCC 6 branch with >> build-many-glibcs.py: >> >> hurdsig.c: In function 'interrupted_reply_port_location.isra.1': >> hurdsig.c:250:39: error: 'portloc' may be used uninitialized in this function [-Werror=maybe-uninitialized] >> *(volatile mach_port_t *) portloc = *portloc; >> ^~~~~~~~ >> >> I haven't investigated whether this warning is valid, or whether it's >> bogus > > Well, it's completely bogus: portloc is initialized just above. I don't > understand why it wouldn't see that. I think it thinks the *value pointed-to by portloc* is uninitialized. Writing that value to a volatile memory location (which happens to be the same memory location, but you specifically told it not to pay attention to that with the volatile cast) is therefore invalid. I don't know this code well enough to suggest what you might could do about that. Since the warning does not happen with GCC 7 or 8 I would be fine with suppressing the diagnostic. zw
On Tue, 3 Apr 2018, Zack Weinberg wrote: > On Tue, Apr 3, 2018 at 5:58 PM, Samuel Thibault <samuel.thibault@gnu.org> wrote: > > Joseph Myers, on mar. 03 avril 2018 21:48:32 +0000, wrote: > >> The build for i686-gnu also fails using GCC 6 branch with > >> build-many-glibcs.py: > >> > >> hurdsig.c: In function 'interrupted_reply_port_location.isra.1': > >> hurdsig.c:250:39: error: 'portloc' may be used uninitialized in this function [-Werror=maybe-uninitialized] > >> *(volatile mach_port_t *) portloc = *portloc; > >> ^~~~~~~~ > >> > >> I haven't investigated whether this warning is valid, or whether it's > >> bogus > > > > Well, it's completely bogus: portloc is initialized just above. I don't > > understand why it wouldn't see that. > > I think it thinks the *value pointed-to by portloc* is uninitialized. This is just after a call to _hurdsig_catch_memory_fault, which is a macro involving a call to setjmp. I think the returns-twice nature of setjmp is confusing the compiler into thinking portloc itself is uninitialized (I don't know why this particular warning) - in fact, the second return of setjmp will never reach the code getting the warning (as setjmp will return nonzero, so _hurdsig_catch_memory_fault will).
On 04/03/2018 11:58 PM, Samuel Thibault wrote: > Joseph Myers, on mar. 03 avril 2018 21:48:32 +0000, wrote: >> The build for i686-gnu also fails using GCC 6 branch with >> build-many-glibcs.py: >> >> hurdsig.c: In function 'interrupted_reply_port_location.isra.1': >> hurdsig.c:250:39: error: 'portloc' may be used uninitialized in this function [-Werror=maybe-uninitialized] >> *(volatile mach_port_t *) portloc = *portloc; >> ^~~~~~~~ >> >> I haven't investigated whether this warning is valid, or whether it's >> bogus > > Well, it's completely bogus: portloc is initialized just above. I don't > understand why it wouldn't see that. You will have to look at the GIMPLE or assembler to determine if the warning is bogus after GCC has processed the setjmp call. It may very well be the case that after those transformations, there *is* an uninitialized use of portloc. Suppressing the warning could be the wrong thing to do here. You may have to declare portloc itself volatile. Thanks a lot for all these Hurd changes, by the way. I really appreciate your work. Thanks, Florian
Joseph Myers, le mar. 03 avril 2018 00:10:30 +0000, a ecrit: > On Mon, 2 Apr 2018, Samuel Thibault wrote: > > Others really pose problem, like ./sysdeps/mach/hurd/bits/fcntl.h's > > l_type/l_whence being int instead of short. > > Where something is problematic to fix, because a fix would break the ABI > or needs some external feature, there is an xfail mechanism internal to > the conform tests. Ok, thanks for the info, I could work it out :) There are some ABI-compatible changes which can be made. One of them is struct shmid_ds's shm_segsz which is int but should be size_t. That is defined as int in both ./sysvipc/sys/shm.h and ./sysdeps/gnu/bits/shm.h. I have checked that the kfreebsd port uses its own shm.h that defines it to size_t. I'd tend to think that we do not have any 64bit port using ./sysvipc/sys/shm.h or ./sysdeps/gnu/bits/shm.h, and thus we can just fix them into size_t since on 32bit ports it is ABI-compatible with int? (except the bitness, but I guess it does not problems in practice?) Samuel
Hello, Samuel Thibault, le jeu. 19 avril 2018 01:57:49 +0200, a ecrit: > I'd tend to think that we do not have any 64bit port using > ./sysvipc/sys/shm.h (I meant include/bits/shm.h here) > or ./sysdeps/gnu/bits/shm.h, and thus we can just fix them into size_t > since on 32bit ports it is ABI-compatible with int? (except the > bitness, but I guess it does not problems in practice?) ping? (Linux has its own bits/shm.h, the kfreebsd port has its own bits/shm.h) Samuel
diff --git a/scripts/build-many-glibcs.py b/scripts/build-many-glibcs.py index 8849574..6095584 100755 --- a/scripts/build-many-glibcs.py +++ b/scripts/build-many-glibcs.py @@ -193,6 +193,8 @@ class Context(object): '--with-fpu=vfpv3']) self.add_config(arch='hppa', os_name='linux-gnu') + self.add_config(arch='i686', + os_name='gnu') self.add_config(arch='ia64', os_name='linux-gnu', first_gcc_cfg=['--with-system-libunwind']) @@ -461,13 +463,15 @@ class Context(object): old_versions = {} self.build_host_libraries() elif action == 'compilers': - build_components = ('binutils', 'gcc', 'glibc', 'linux') + build_components = ('binutils', 'gcc', 'glibc', 'linux', 'mig', + 'gnumach', 'hurd') old_components = ('gmp', 'mpfr', 'mpc') old_versions = self.build_state['host-libraries']['build-versions'] self.build_compilers(configs) else: build_components = ('glibc',) - old_components = ('gmp', 'mpfr', 'mpc', 'binutils', 'gcc', 'linux') + old_components = ('gmp', 'mpfr', 'mpc', 'binutils', 'gcc', 'linux', + 'mig', 'gnumach', 'hurd') old_versions = self.build_state['compilers']['build-versions'] self.build_glibcs(configs) self.write_files() @@ -694,7 +698,10 @@ class Context(object): 'gmp': '6.1.2', 'linux': '4.14', 'mpc': '1.1.0', - 'mpfr': '4.0.0'} + 'mpfr': '4.0.0', + 'mig': '1.8', + 'gnumach': '1.8', + 'hurd': '0.9'} use_versions = {} explicit_versions = {} for v in versions: @@ -829,7 +836,10 @@ class Context(object): 'gmp': 'https://ftp.gnu.org/gnu/gmp/gmp-%(version)s.tar.xz', 'linux': 'https://www.kernel.org/pub/linux/kernel/v4.x/linux-%(version)s.tar.xz', 'mpc': 'https://ftp.gnu.org/gnu/mpc/mpc-%(version)s.tar.gz', - 'mpfr': 'https://ftp.gnu.org/gnu/mpfr/mpfr-%(version)s.tar.xz'} + 'mpfr': 'https://ftp.gnu.org/gnu/mpfr/mpfr-%(version)s.tar.xz', + 'mig': 'https://ftp.gnu.org/gnu/mig/mig-%(version)s.tar.bz2', + 'gnumach': 'https://ftp.gnu.org/gnu/gnumach/gnumach-%(version)s.tar.bz2', + 'hurd': 'https://ftp.gnu.org/gnu/hurd/hurd-%(version)s.tar.bz2'} if component not in url_map: print('error: component %s coming from tarball' % component) exit(1) @@ -949,7 +959,8 @@ class Context(object): self.clear_last_build_state(a) self.exec_self() check_components = {'host-libraries': ('gmp', 'mpfr', 'mpc'), - 'compilers': ('binutils', 'gcc', 'glibc', 'linux'), + 'compilers': ('binutils', 'gcc', 'glibc', 'linux', + 'mig', 'gnumach', 'hurd'), 'glibcs': ('glibc',)} must_build = {} for a in actions: @@ -1148,6 +1159,10 @@ class Config(object): if self.os.startswith('linux'): self.install_linux_headers(cmdlist) self.build_gcc(cmdlist, True) + if self.os == 'gnu': + self.install_gnumach_headers(cmdlist) + self.build_cross_tool(cmdlist, 'mig', 'mig') + self.install_hurd_headers(cmdlist) for g in self.compiler_glibcs: cmdlist.push_subdesc('glibc') cmdlist.push_subdesc(g.name) @@ -1230,6 +1245,41 @@ class Config(object): cmdlist.cleanup_dir() cmdlist.pop_subdesc() + def install_gnumach_headers(self, cmdlist): + """Install GNU Mach headers.""" + srcdir = self.ctx.component_srcdir('gnumach') + builddir = self.component_builddir('gnumach') + cmdlist.push_subdesc('gnumach') + cmdlist.create_use_dir(builddir) + cmdlist.add_command('configure', + [os.path.join(srcdir, 'configure'), + '--build=%s' % self.ctx.build_triplet, + '--host=%s' % self.triplet, + '--prefix=', + 'CC=%s-gcc -nostdlib' % self.triplet]) + cmdlist.add_command('install', ['make', 'DESTDIR=%s' % self.sysroot, + 'install-data']) + cmdlist.cleanup_dir() + cmdlist.pop_subdesc() + + def install_hurd_headers(self, cmdlist): + """Install Hurd headers.""" + srcdir = self.ctx.component_srcdir('hurd') + builddir = self.component_builddir('hurd') + cmdlist.push_subdesc('hurd') + cmdlist.create_use_dir(builddir) + cmdlist.add_command('configure', + [os.path.join(srcdir, 'configure'), + '--build=%s' % self.ctx.build_triplet, + '--host=%s' % self.triplet, + '--prefix=', + '--disable-profile', '--without-parted', + 'CC=%s-gcc -nostdlib' % self.triplet]) + cmdlist.add_command('install', ['make', 'prefix=%s' % self.sysroot, + 'no_deps=t', 'install-headers']) + cmdlist.cleanup_dir() + cmdlist.pop_subdesc() + def build_gcc(self, cmdlist, bootstrap): """Build GCC.""" # libsanitizer commonly breaks because of glibc header @@ -1346,8 +1396,10 @@ class Glibc(object): # writing into the working directory. To avoid possible # concurrency issues, copy the source directory. cmdlist.create_copy_dir(srcdir, srcdir_copy) + use_usr = self.os != 'gnu' + prefix = '/usr' if use_usr else '' cfg_cmd = [os.path.join(srcdir_copy, 'configure'), - '--prefix=/usr', + '--prefix=%s' % prefix, '--enable-profile', '--build=%s' % self.ctx.build_triplet, '--host=%s' % self.triplet, @@ -1362,6 +1414,8 @@ class Glibc(object): 'RANLIB=%s' % self.tool_name('ranlib'), 'READELF=%s' % self.tool_name('readelf'), 'STRIP=%s' % self.tool_name('strip')] + if self.os == 'gnu': + cfg_cmd += ['MIG=%s' % self.tool_name('mig')] cfg_cmd += self.cfg cmdlist.add_command('configure', cfg_cmd) cmdlist.add_command('build', ['make']) @@ -1369,10 +1423,11 @@ class Glibc(object): 'install_root=%s' % installdir]) # GCC uses paths such as lib/../lib64, so make sure lib # directories always exist. - cmdlist.add_command('mkdir-lib', ['mkdir', '-p', - os.path.join(installdir, 'lib'), - os.path.join(installdir, - 'usr', 'lib')]) + mkdir_cmd = ['mkdir', '-p', + os.path.join(installdir, 'lib')] + if use_usr: + mkdir_cmd += [os.path.join(installdir, 'usr', 'lib')] + cmdlist.add_command('mkdir-lib', mkdir_cmd) if not for_compiler: if self.ctx.strip: cmdlist.add_command('strip',