public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Yury Norov <ynorov@caviumnetworks.com>
To: Florian Weimer <fweimer@redhat.com>
Cc: Maxim Kuvyrkov <maxim.kuvyrkov@linaro.org>,
	GNU C Library <libc-alpha@sourceware.org>
Subject: Re: ILP32 for ARM64: testing with glibc testsuite
Date: Thu, 24 Nov 2016 09:00:00 -0000	[thread overview]
Message-ID: <20161124085936.GA23245@yury-N73SV> (raw)
In-Reply-To: <f0884ddb-65c2-027d-422f-2e3d947305e4@redhat.com>

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.

> 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.
Andrew has it passed for vanilla glibc as well.

> >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.

Yury.

  reply	other threads:[~2016-11-24  9:00 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1477081997-4770-1-git-send-email-ynorov@caviumnetworks.com>
2016-11-07  8:24 ` Yury Norov
2016-11-09  9:57   ` Yury Norov
2016-11-16 11:26     ` Maxim Kuvyrkov
2016-11-16 13:08       ` Yury Norov
2016-11-24  5:16       ` Yury Norov
2016-11-24  7:36         ` Florian Weimer
2016-11-24  9:00           ` Yury Norov [this message]
2016-11-24  9:06             ` Florian Weimer
2016-11-24  9:10               ` Andrew Pinski
2016-11-25 14:26         ` Ramana Radhakrishnan
2016-11-25 15:30           ` Yury Norov
     [not found]     ` <CC4F99A7-1FD2-486A-BD66-ED06F1B8BF50@linaro.org>
     [not found]       ` <1479419136.908.90.camel@caviumnetworks.com>
2016-12-05 10:02         ` Zhangjian (Bamvor)
2016-12-05 10:07           ` Andreas Schwab
2016-12-05 10:26             ` Zhangjian (Bamvor)
2016-12-06  5:29               ` Yury Norov
     [not found]             ` <1480966437.29811.23.camel@caviumnetworks.com>
2016-12-06  8:31               ` Andreas Schwab
     [not found] ` <20161028124659.GA24131@yury-N73SV>
     [not found]   ` <cdf5cdf2-43af-6d7f-9e0c-72675fb83224@huawei.com>
     [not found]     ` <266952F2-53F5-4D5E-83F0-6C8203092F67@linaro.org>
     [not found]       ` <120041af-f4e9-5b6f-36dc-7d3535a1f01c@huawei.com>
2016-12-05 10:23         ` ILP32 for ARM64 - testing with lmbench Zhangjian (Bamvor)
     [not found]           ` <20161205141312.GC14429@e104818-lin.cambridge.arm.com>
2016-12-11 12:08             ` Yury Norov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20161124085936.GA23245@yury-N73SV \
    --to=ynorov@caviumnetworks.com \
    --cc=fweimer@redhat.com \
    --cc=libc-alpha@sourceware.org \
    --cc=maxim.kuvyrkov@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).