From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 117431 invoked by alias); 2 Apr 2018 15:50:27 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 116818 invoked by uid 89); 2 Apr 2018 15:50:24 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.1 required=5.0 tests=BAYES_00,SPF_HELO_PASS,SPF_NEUTRAL autolearn=no version=3.3.2 spammy=permit, hundred X-HELO: hera.aquilenet.fr Date: Mon, 02 Apr 2018 15:50:00 -0000 From: Samuel Thibault To: Joseph Myers Cc: Florian Weimer , Thomas Schwinge , GNU C Library , bug-hurd@gnu.org, David Michael Subject: Re: Upstreaming the glibc Hurd port Message-ID: <20180402155017.iermidp5siqgcixv@var.youpi.perso.aquilenet.fr> Mail-Followup-To: Joseph Myers , Florian Weimer , Thomas Schwinge , GNU C Library , bug-hurd@gnu.org, David Michael References: <87a7xaupjx.fsf@euler.schwinge.homeip.net> <20180124011051.5s2vugyq3ybnurwc@var.youpi.perso.aquilenet.fr> <20180124012726.tibylwp4re5dtgc3@var.youpi.perso.aquilenet.fr> <20180125014143.2hxhzon5lzxtqq6j@var.youpi.perso.aquilenet.fr> <20180319015122.j5tzslkdcnvampoh@var.youpi.perso.aquilenet.fr> <20180402001003.3u5n2p5pdmv4hos5@var.youpi.perso.aquilenet.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) X-SW-Source: 2018-04/txt/msg00021.txt.bz2 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