Re: [PATCH 2/2] New internal function __access_noerrno

[Adhemerval Zanella <adhemerval.zanella@linaro.org>]

On 17/11/2016 22:21, Kalle Olavi Niemitalo wrote:
> Adhemerval Zanella <adhemerval.zanella@linaro.org> writes:
> 
>> Below is all the fixes you proposed, if you think it is ok I will
>> prepare a patch and commit.
> 
> Thanks.  It looks like an improvement.
> I'd like to do some testing during the weekend.

I pushed a patch based on the RFC I sent earlier.

> 
> However, I suspect that this __access_noerrno may be unsafe to run
> during initialization of tunables on the Hurd.  access_common calls
> __hurd_file_name_lookup, which calls __hurd_file_name_lookup_retry,
> which can use errno, __strtoul_internal, _itoa, strcpy, and memcmp.
> I'm not yet sure whether this is a problem, and I'm not asking you
> to spend time on it.
> 

I think it might be an issue depending of whether errno is accessible
on tunables initialization (it might be the case where is not yet
relocated/allocated).  Anyway I do not have a working system to 
actually even test a build on Hurd (the instruction at [1] points
to a non bootable VM).

If you could provide us with a working toolchain or a working VM
to actually check hurd builds it would be valuable.  Also it could
be case to add a hurd configuration to build-many-glibcs.py.

[1] https://www.gnu.org/software/hurd/hurd/running/qemu.html