From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 111034 invoked by alias); 2 Apr 2018 14:17:46 -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 111024 invoked by uid 89); 2 Apr 2018 14:17:46 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS,URIBL_RED autolearn=ham version=3.3.2 spammy= X-HELO: relay1.mentorg.com Date: Mon, 02 Apr 2018 14:17:00 -0000 From: Joseph Myers To: Samuel Thibault CC: Florian Weimer , Thomas Schwinge , GNU C Library , , David Michael Subject: Re: Upstreaming the glibc Hurd port In-Reply-To: <20180402001003.3u5n2p5pdmv4hos5@var.youpi.perso.aquilenet.fr> Message-ID: References: <20180118235924.r4z4ppvj7xlvmmfp@var.youpi.perso.aquilenet.fr> <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> 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) X-SW-Source: 2018-04/txt/msg00013.txt.bz2 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). -- Joseph S. Myers joseph@codesourcery.com