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 jos...@codesourcery.com
