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
