From: Christophe Lyon <christophe.lyon@linaro.org>
To: Alan Modra <amodra@gmail.com>
Cc: Tamar Christina <Tamar.Christina@arm.com>,
binutils <binutils@sourceware.org>, nd <nd@arm.com>
Subject: Re: [PATCH] Add support for non-contiguous memory regions
Date: Thu, 20 Feb 2020 04:37:00 -0000 [thread overview]
Message-ID: <CAKdteObVAUJd-z4U1U3DDP-H-CWSD+Z=YiDKLXj8RasVGEr4tg@mail.gmail.com> (raw)
In-Reply-To: <20200219222336.GU5570@bubble.grove.modra.org>
On Wed, 19 Feb 2020 at 23:23, Alan Modra <amodra@gmail.com> wrote:
>
> On Wed, Feb 19, 2020 at 01:28:23PM +0100, Christophe Lyon wrote:
> > On Wed, 19 Feb 2020 at 08:19, Alan Modra <amodra@gmail.com> wrote:
> > >
> > > On Fri, Feb 14, 2020 at 02:53:55PM +0100, Christophe Lyon wrote:
> > > > Here are the updated patches.
> > >
> > > Wrong set of patches? elfnn-aarch64.c, elf32-metag.c, and
> > > elf32-nios2.c won't compile with these patches applied. All due to
> > > missing "struct bfd_link_info *info;" in build_one_stub.
> > >
> >
> > Oops, thanks for noticing.
> > I don't understand what happened. Here's the right version (the only
> > difference is the declaration of struct bfd_link_info *info; in
> > build_one_stub.
>
Hi Alan,
Thanks for the feedback.
> The test results don't inspire me with confidence. A lot of the fails
> are due to targets not supporting -mlittle-endian, but there are other
> fails that show the patch series needs more work before it is ready
> for review. Also, please don't write tests that require one
> particular endianness. Write the objdump match patterns to suit both
> endians instead. Something like this:
>
> Contents of section \.raml:
> 1fff0000 (010+ 020+ 030+|0+01 0+02 0+03) .*
>
OK, I was wondering/hoping there's a nicer way of achieving this. I'll
update my patch to use this pattern.
>
> alpha-linux FAIL: non-contiguous
> alpha-netbsd FAIL: non-contiguous
> alpha-unknown-freebsd4.7 FAIL: non-contiguous
> am33_2.0-linux FAIL: non-contiguous
> arc-elf FAIL: non-contiguous
> arc-linux-uclibc FAIL: non-contiguous
> arm-nacl FAIL: non-contiguous-arm2
> arm-nacl FAIL: non-contiguous-arm3
> arm-nacl FAIL: non-contiguous-arm5
> arm-nacl FAIL: non-contiguous-arm6
> bfin-elf FAIL: non-contiguous
> bfin-linux-uclibc FAIL: non-contiguous
> cr16-elf FAIL: non-contiguous
> cris-elf FAIL: non-contiguous
> cris-linux FAIL: non-contiguous
> crisv32-linux FAIL: non-contiguous
> crx-elf FAIL: non-contiguous
> d10v-elf FAIL: non-contiguous
> epiphany-elf FAIL: non-contiguous
> fr30-elf FAIL: non-contiguous
> frv-elf FAIL: non-contiguous
> frv-linux FAIL: non-contiguous
> ft32-elf FAIL: non-contiguous
> h8300-elf FAIL: non-contiguous
> h8300-linux FAIL: non-contiguous
> i386-lynxos FAIL: non-contiguous
> i586-linux FAIL: non-contiguous
> i686-nacl FAIL: non-contiguous
> i686-nto FAIL: non-contiguous
> i686-pc-elf FAIL: non-contiguous
> ia64-elf FAIL: non-contiguous
> ia64-freebsd5 FAIL: non-contiguous
> ia64-linux FAIL: non-contiguous
> ia64-netbsd FAIL: non-contiguous
> ip2k-elf FAIL: non-contiguous
> iq2000-elf FAIL: non-contiguous
> lm32-elf FAIL: non-contiguous
> lm32-linux FAIL: non-contiguous
> m32c-elf FAIL: non-contiguous
> m32r-elf FAIL: non-contiguous
> m32r-linux FAIL: non-contiguous
> m68k-elf FAIL: non-contiguous
> m68k-linux FAIL: non-contiguous
> mcore-elf FAIL: non-contiguous
> mep-elf FAIL: non-contiguous
> microblaze-elf FAIL: non-contiguous
> microblaze-linux FAIL: non-contiguous
> mips64el-openbsd FAIL: non-contiguous
> mips64-linux FAIL: non-contiguous
> mips64-openbsd FAIL: non-contiguous
> mipsel-linux-gnu FAIL: non-contiguous
> mipsisa32el-linux FAIL: non-contiguous
> mips-linux FAIL: non-contiguous
> mips-sgi-irix6 FAIL: non-contiguous
> mipstx39-elf FAIL: non-contiguous
> mn10200-elf FAIL: non-contiguous
> mn10300-elf FAIL: non-contiguous
> moxie-elf FAIL: non-contiguous
> msp430-elf FAIL: non-contiguous
> mt-elf FAIL: non-contiguous
> nds32be-elf FAIL: non-contiguous
> nds32le-linux FAIL: non-contiguous
> or1k-elf FAIL: non-contiguous
> or1k-linux FAIL: non-contiguous
> powerpc64-freebsd FAIL: non-contiguous-powerpc
> powerpc64le-linux FAIL: non-contiguous-powerpc
> powerpc64-linux FAIL: non-contiguous-powerpc
> powerpc-freebsd FAIL: non-contiguous
> pru-elf FAIL: non-contiguous
> riscv32-elf FAIL: non-contiguous
> riscv64-linux FAIL: non-contiguous
> rl78-elf FAIL: non-contiguous
> s390-linux FAIL: non-contiguous
> s390x-linux FAIL: non-contiguous
> score-elf FAIL: non-contiguous
> shle-unknown-netbsdelf FAIL: non-contiguous
> sh-linux FAIL: non-contiguous
> sh-nto FAIL: non-contiguous
> sh-rtems FAIL: non-contiguous
> sparc64-linux FAIL: non-contiguous
> sparc-elf FAIL: non-contiguous
> sparc-linux FAIL: non-contiguous
> sparc-sun-solaris2 FAIL: non-contiguous
> spu-elf FAIL: non-contiguous
> tic6x-elf FAIL: non-contiguous
> tilegx-linux FAIL: non-contiguous
> tilepro-linux FAIL: non-contiguous
> v850-elf FAIL: non-contiguous
> vax-netbsdelf FAIL: non-contiguous
> visium-elf FAIL: non-contiguous
> x86_64-cloudabi FAIL: non-contiguous
> x86_64-linux FAIL: non-contiguous
> x86_64-nacl FAIL: non-contiguous
> x86_64-pc-linux-gnux32 FAIL: non-contiguous
> xc16x-elf FAIL: non-contiguous
> xstormy16-elf FAIL: non-contiguous
> xtensa-elf FAIL: non-contiguous
> z80-elf FAIL: non-contiguous
>
So... I did run the tests on a few targets, but obviously not this long list.
How do you manage this? Is that list maintained somewhere?
Are there scripts to exercise all these targets? (--enable-targets=all
is not enough AFAICT)
Or should I just copy & paste that list from your email and
for i in <that-list>
do
configure --target=$i
make all check
done
Thanks,
Christophe
> --
> Alan Modra
> Australia Development Lab, IBM
next prev parent reply other threads:[~2020-02-20 4:37 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-14 12:34 Christophe Lyon
2020-02-14 13:02 ` Tamar Christina
2020-02-14 13:54 ` Christophe Lyon
2020-02-19 7:19 ` Alan Modra
2020-02-19 12:28 ` Christophe Lyon
2020-02-19 22:23 ` Alan Modra
2020-02-20 4:37 ` Christophe Lyon [this message]
2020-02-20 8:15 ` Alan Modra
2020-02-20 9:00 ` Christophe Lyon
2020-02-28 17:31 ` Christophe Lyon
2020-03-09 13:10 ` Christophe Lyon
2020-03-13 14:21 ` Nick Clifton
2020-03-13 14:46 ` Christophe Lyon
2020-06-02 12:49 ` Alexander Fedotov
2020-06-03 12:48 ` Christophe Lyon
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='CAKdteObVAUJd-z4U1U3DDP-H-CWSD+Z=YiDKLXj8RasVGEr4tg@mail.gmail.com' \
--to=christophe.lyon@linaro.org \
--cc=Tamar.Christina@arm.com \
--cc=amodra@gmail.com \
--cc=binutils@sourceware.org \
--cc=nd@arm.com \
/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).