Re: Upstreaming the glibc Hurd port

[Joseph Myers]

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