From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 34499 invoked by alias); 24 Nov 2016 09:10:07 -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 34486 invoked by uid 89); 24 Nov 2016 09:10:06 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy= X-HELO: mail-yw0-f175.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lWCtm9k8qSo/BLUj9ggaAeAm2SnfhP4ZGMVU5VJpgnw=; b=N5340pXUN6iXaq0kRIzyu4Yg/d4TnzS/BYl2oXYvxCqiPzJTogBFd0ZJz+eMQ8xG8T aha9BSk4kvsWpy8lU6jhIZ/7yBiPlOn77zZ30gzIYRb8iR/qBQqW87Sftp2YGDSQ122J c5E+FhjPt10QyBzb3EuQYwYV3AkQLkbEbWAljjoAEAaVbZiJRI90rdmozBXFmGG1XUbz YbYN3ssluUwPjf9Dz0nCOIlypDepqchEQ9osmNy3I9JCPtq79wHg5faYESLxzfXKrJFx CoFBbZW5pvPSX8pepKFziQ0n4o9y2Mgr36K8NZzyV2MM1I7Sk1Tpv5gFNOav5SfRs11s ktZw== X-Gm-Message-State: AKaTC03SwO6w0UfKZFXYRSdHrhh13h5+2zjqQMJBADBm1D+VfnpTDMYmhEfF6P32kBAwz7TuP+ZRfrYRC/V5tw== X-Received: by 10.129.95.11 with SMTP id t11mr1924274ywb.128.1479978595031; Thu, 24 Nov 2016 01:09:55 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <141abb38-ef20-ac1f-9729-24fa14cae32b@redhat.com> References: <1477081997-4770-1-git-send-email-ynorov@caviumnetworks.com> <20161107082359.GA19666@yury-N73SV> <20161109095650.GA22804@yury-N73SV> <20161124051539.GA5365@yury-N73SV> <20161124085936.GA23245@yury-N73SV> <141abb38-ef20-ac1f-9729-24fa14cae32b@redhat.com> From: Andrew Pinski Date: Thu, 24 Nov 2016 09:10:00 -0000 Message-ID: Subject: Re: ILP32 for ARM64: testing with glibc testsuite To: Florian Weimer Cc: Yury Norov , Maxim Kuvyrkov , GNU C Library Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2016-11/txt/msg00875.txt.bz2 On Thu, Nov 24, 2016 at 1:06 AM, Florian Weimer wrote: > On 11/24/2016 09:59 AM, Yury Norov wrote: >> >> On Thu, Nov 24, 2016 at 08:36:16AM +0100, Florian Weimer wrote: >>> >>> On 11/24/2016 06:15 AM, Yury Norov wrote: >>> >>>> Conform tests fail most probably because I have vanilla headers at >>>> standard paths (/usr/include). Modified headers are under different >>>> testing location. Steve also tested it, and he has modified headers at >>>> /usr/include, and he doesn't see failures of conform tests. I don't >>>> think that kernel or wrong ABI caused this regression. Most probably >>>> it's configuration issue. I also think that glibc should take headers >>> >>> >from testing directory, not from standard paths. For me it's dangerous >>>> >>>> to replace standard headers with untested ones. Is there some option >>>> in glibc testsuite configuration to provide path to headers explicitly? >>> >>> >>> There is something peculiar with your test setup, I think. The conform >>> tests do not do that for me. How do you configure, build, and test >>> glibc? >> >> >> This is my makefile to build it. >> https://github.com/norov/build-glibc >> >> If you have thoughts how to make it work right, I'll be really >> appreciated. > > > Are you cross-compiling? I did not expect that. I thought native > development was possible on aarch64 now. > >>> The instability in the malloc tests need investigation as well. If you >>> run >>> this on a simulator, you need to increase the test timeout. >> >> >> I run it on qemu. It doesn't look like instability. malloc tests >> always fail on vanilla glibc, and always pass on patched one, for me. > > > Have you tried to increase test timeout? > >> Andrew has it passed for vanilla glibc as well. > > > Does Andrew use QEMU as well? Mine was native on a ThunderX T88 machine with a vanilla linux 4.8rc3. Thanks, Andrew > >>>> elf/* tests fail only in ILP32 mode. We tracked it down to the linker >>>> problem that replaces accesses to TLS with direct address calculation >>>> if possible, and does it wrong for ilp32. This is definitely a linker >>>> problem, and ABI and kernel are not involved here. >>> >>> >>> The elf/check-localplt failure may have a different cause. What does the >>> test report in the .out file? >> >> >> yury@yury-N73SV:~/work/glibc-img/lp64.build$ cat ./elf/check-localplt.out >> Extra PLT reference: libc.so: renameat >> >> Seems yes, it doesn't look like a TLS problem. I'll check it. > > > Thanks. > > Florian >