From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 120000 invoked by alias); 18 Nov 2016 18:54:05 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 119961 invoked by uid 89); 18 Nov 2016 18:54:04 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=kalle, olavi, Niemitalo, Kalle X-HELO: mail-ua0-f182.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=NVRubo/LAfUrmkTmeI5iiq6vSHh1eUkLRcNgGCbULi8=; b=PH0ceLIAfKK7gmyvdbtZYybKEf93Dprmu45TJMGtOWAIP5ukd+UJIrVlV+xRuHMLOD nF5eSEqmMlac1VtOt6MkGtdbu7qpRT44lljW8ev8jvpeCTq8FvD/i1ceicDkaNcFa2My obH2UwexaEKMEJIbY6viu14IWX7KrFYdGbuVraomPzeFd0BjgfSeYybX8c3GtJ5Kzko+ lJAa0a0W4n+f4tJFUs5DtbvqL+ZMlBeUDNmeIjjlFJRthJTBmJgPDcjGtj6eeCdr8wYG Q6ZbX2QN/jb5SPWPKCFMGmaRYnR8aLqB2Q4KppRfBpdTAUVF88vjmANh0xAqO5ujeQQc TUZA== X-Gm-Message-State: AKaTC02BAlU8eBo/GWuCGfSSdhD+DvRPIrfkr7ykOTbPm2Y3O0OVzYsg1Z0b7TrICSp1lEtI X-Received: by 10.159.34.42 with SMTP id 39mr863134uad.84.1479495232469; Fri, 18 Nov 2016 10:53:52 -0800 (PST) Subject: Re: [PATCH 2/2] New internal function __access_noerrno To: libc-alpha@sourceware.org References: <1478797446-12213-1-git-send-email-adhemerval.zanella@linaro.org> <1478797446-12213-2-git-send-email-adhemerval.zanella@linaro.org> <083c6da8-5c67-acba-f7f0-79fb4253d7d2@gotplt.org> <23ef1354-7ade-70fe-46f0-59392798ef82@linaro.org> <60199742-d6f4-3f2a-ad38-619dcfdc7954@linaro.org> <87r369j093.fsf@Niukka.kon.iki.fi> <87inrliqmx.fsf@Niukka.kon.iki.fi> From: Adhemerval Zanella Message-ID: <0b12c716-a973-8cad-4982-216fd0a1495e@linaro.org> Date: Fri, 18 Nov 2016 18:54:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <87inrliqmx.fsf@Niukka.kon.iki.fi> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-11/txt/msg00674.txt.bz2 On 17/11/2016 22:21, Kalle Olavi Niemitalo wrote: > Adhemerval Zanella 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