This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 2/2] New internal function __access_noerrno
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