Re: how to build and test uClinux toolchains
On Wed, 31 Oct 2018 at 16:43, Christophe Lyon
wrote:
>
> On Fri, 26 Oct 2018 at 19:54, Max Filippov wrote:
> >
> > On Fri, Oct 26, 2018 at 6:51 AM Christophe Lyon
> > wrote:
> > > On Sun, 21 Oct 2018 at 04:06, Max Filippov wrote:
> > > > Probably the easiest way to get all xtensa toolchain parts correctly it
> > > > by using existing buildroot configuration. E.g. the following
> > > > configuration
> > > > may be used to build uclinux xtensa toolchain for the dc233c core:
> > > > https://git.buildroot.net/buildroot/tree/configs/qemu_xtensa_lx60_nommu_defconfig
> > > >
> > > OK, thanks for your suggestion. I think I managed to build it.
> > > Now, how/where can I run 'make check' for gcc?
> > > I do not see the GCC build tree.
> >
> > The gcc build tree is usually in the build/host-gcc-final in the buildroot
> > build tree. But that's gcc version selected in the buildroot, you probably
> > want a different version. Usually after the buildroot toolchain is ready I
> > build gcc separately using binutils and sysroot produced by the buildroot.
> > I have a few examples here:
> >
> > http://wiki.osll.ru/doku.php/etc:users:jcmvbkbc:gcc-xtensa-call0
> >
> > Please note that you'd need to apply gcc part of the xtensa overlay to
> > your gcc source for it to correctly generate code for that configuration.
> >
> > I've run the tests with the current gcc trunk and a lot of execution
> > tests related to TLS (which is expected) and exceptions (which I
> > didn't expect) are failing. I'm looking at it.
> >
>
> I'm not sure if I followed the instructions correctly:
> make qemu_xtensa_lx60_nommu_defconfig
> make all
> which built:
> ./output/host/bin/xtensa-buildroot-uclinux-uclibc-gcc (which is 7.3)
> then I tried to follow the wiki above:
> export TOOLCHAIN=$PWD/output
> PATH=$TOOLCHAIN/host/bin:$PATH /gcc/configure [...]
>
> I also built qemu from the branch you mentioned,
> and used the "run it on linux-user QEMU" section in the wiki
>
> I see many execution errors, now realizing that I didn't
> do what you said above: "apply gcc part of the xtensa overlay".
> But what is this? Do you mean the patches in buildroot/packages/gcc/8.2.0 ?
> I tried to apply 0004-gcc-xtensa-fix-NAND-code-in-xtensa_expand_atomic.patch
> but patch says it's already applied (I'm using GCC trunk)
>
> And while writing this reply, I'm just realizing that buildroot builds
> for uclinux-uclibc-gcc, while the wiki uses linux-uclibc :(
> Does the wiki need an update wrt target name?
>
I re-ran the wiki instructions with --target=xtensa-buildroot-uclinux-uclibc
and while gcc/g++ results looks mostly OK, the libstdc++ ones only show:
Running ...f/trunk/libstdc++-v3/testsuite/libstdc++-abi/abi.exp ...
ERROR: could not compile testsuite_abi.cc
ERROR: tcl error sourcing.../trunk/libstdc++-v3/testsuite/libstdc++-abi/abi.exp.
Running.../trunk/libstdc++-v3/testsuite/libstdc++-dg/conformance.exp ...
ERROR: could not compile testsuite_abi.cc
etc...
libstdc++.log show many instances of:
.../trunk/libstdc++-v3/testsuite/util/testsuite_abi.cc: In function
'symbols create_symbols(const char*)':^M
.../trunk/libstdc++-v3/testsuite/util/testsuite_abi.cc:565: note:
non-delegitimized UNSPEC 3 found in variable location^M
.../trunk/libstdc++-v3/testsuite/util/testsuite_abi.cc: In function
'void examine_symbol(const char*, const char*)':^M
.../trunk/libstdc++-v3/testsuite/util/testsuite_abi.cc:355: note:
non-delegitimized UNSPEC 3 found in variable location^M
ERROR: tcl error sourcing
.../trunk/libstdc++-v3/testsuite/libstdc++-abi/abi.exp.
ERROR: could not compile testsuite_abi.cc
while executing
"error "could not compile $f""
(procedure "v3-build_support" line 62)
invoked from within
"v3-build_support"
(file ".../trunk/libstdc++-v3/testsuite/libstdc++-abi/abi.exp" line 34)
invoked from within
"source .../trunk/libstdc++-v3/testsuite/libstdc++-abi/abi.exp"
("uplevel" body line 1)
invoked from within
"uplevel #0 source .../trunk/libstdc++-v3/testsuite/libstdc++-abi/abi.exp"
invoked from within
"catch "uplevel #0 source $test_file_name""
Do you know what the problem is in my setup? Or with GCC trunk?
> > > > Also bFLT executable format is currently not supported for linux-user
> > > > xtensa QEMU. The following branch adds that support:
> > > > https://github.com/OSLL/qemu-xtensa/commits/xtensa-bflt
> > > >
> > > > qemu-xtensa built from this QEMU then may be registered as a binfmt
> > > > handler for bFLT executable images allowing to run gcc tests that want
> > > > to run target binaries.
> > > Do you have the magic commands for this?
> >
> > If you build QEMU from the link above you can use the following command
> > to register binfmt handler for bFLT binaries assuming that you've installed
> > it into $QEMU_PREFIX:
> >
> > sudo scripts/qemu-binfmt-conf.sh --qemu-path=$QEMU_PREFIX/bin --flat
> > 'xtensa'
> >
> > The --flat switch is not final, it will likely change before it's accepted
> > to
> > the QEMU mainline.
Re: LRA reload produces invalid insn
> On Nov 1, 2018, at 8:49 PM, Peter Bergner wrote: > > On 11/1/18 7:25 PM, Paul Koning wrote: >> I'm running the testsuite on the pdp11 target, and I get a failure when >> using LRA that works correctly with the old allocator. The issue is that >> LRA is producing an insn that is invalid (it violates the constraints stated >> in the insn definition). > [snip] >> which is the correct sequence given the matching operand constraint in the >> define_insn. >> >> Is this an LRA bug, or is there something I need to do in the target to >> prevent this happening? > > What do you mean by "old allocator"? Just an older revision? Does it work > before my > revision 264897 commit and broken after? If so, could you try the following > to see > whether that fixes things for you? > >https://gcc.gnu.org/ml/gcc-patches/2018-10/msg01757.html > > My commit above exposed some latent LRA bugs and my patch above tries > to fix issues similar to what you're seeing. > > Peter That doesn't cure this particular problem; the ICE is still there with the same error message (identical failing insn) as before. paul
Re: LRA reload produces invalid insn
On 11/1/18 10:37 PM, Vladimir Makarov wrote: > On 11/01/2018 08:25 PM, Paul Koning wrote: >> Is this an LRA bug, or is there something I need to do in the target to >> prevent this happening? > It is hard to say whose code is responsible for this. It might be a wrong > machine-dependent code or a LRA bug. > > Paul, could you send me full LRA dump file (.reload). It might help me to > say more specific reason for the bug. LRA has iterated sub-passes and the > full dump can say where LRA started to behave wrongly. > I'll note that when we ported the rs6000 (ie, ppc*) port over to LRA from reload, we hit many target problems. It seems LRA is much less forgiving to bad constraints, predicates, etc. than reload was. I think that's actually a good thing. Peter
Re: LRA reload produces invalid insn
> On Nov 2, 2018, at 9:34 AM, Peter Bergner wrote: > > On 11/1/18 10:37 PM, Vladimir Makarov wrote: >> On 11/01/2018 08:25 PM, Paul Koning wrote: >>> Is this an LRA bug, or is there something I need to do in the target to >>> prevent this happening? >> It is hard to say whose code is responsible for this. It might be a wrong >> machine-dependent code or a LRA bug. >> >> Paul, could you send me full LRA dump file (.reload). It might help me to >> say more specific reason for the bug. LRA has iterated sub-passes and the >> full dump can say where LRA started to behave wrongly. >> > > I'll note that when we ported the rs6000 (ie, ppc*) port over to LRA > from reload, we hit many target problems. It seems LRA is much less > forgiving to bad constraints, predicates, etc. than reload was. > I think that's actually a good thing. > > Peter Yes, I ran into that, and Segher (I think) helped me with a bad predicate case. It doesn't help that the documentation isn't all that explicit about what the requirements are. paul
gcc-8-20181102 is now available
Snapshot gcc-8-20181102 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/8-20181102/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 8 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-8-branch revision 265762 You'll find: gcc-8-20181102.tar.xzComplete GCC SHA256=8e5464fe0e69eb774a47efe64da9739a1766a6d845c4b149c717d09ea962f082 SHA1=8e51ba693f9c3594d3a010e8a15caace1ea4b5d5 Diffs from 8-20181026 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-8 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: dg-add-options ieee ?
On 10/31/18 3:27 PM, Rainer Orth wrote:
> Hi Paul,
>
>>> On Oct 31, 2018, at 4:11 PM, Rainer Orth
>>> wrote:
>>>
>>> Hi Paul,
>>>
Ok, thanks. So adding a dg-skip-if for my target is indeed correct.
Will do so.
>>>
>>> please don't: since this is going to be common, please add a
>>> corresponding effective-target keyword instead, together with
>>> sourcebuild.texi documentation. That's far more expressive than
>>> explicit target lists.
>>>
>>> Thanks.
>>>Rainer
>>
>> So you mean, add a new keyword (say, "ieee") to dg-effective-target that
>> means "run this test only on ieee targets"?
>
> right.
>
>> Another approach might be to have dg-add-options ieee mean what it does
>> today, but also have it skip the test for non-ieee capable targets. Or is
>> that undesirable because it muddles the meaning of the dg-add-options
>> keyword? I figure it would make sense because any test that has
>> dg-add-options ieee by definition should be skipped by any target that
>> can't do ieee at all.
>
> No, that's not how things are supposed to work. Look at c99_runtime for
> example: we have both
>
> dg-require-effective-target c99_runtime
>
> which checks if the targets supports a C99 runtime, and
>
> dg-add-options c99_runtime
>
> to add special options for targets that need them.
>
> I've no idea why this isn't the case for ieee today.
Probably because we've buried a lot of the ieee specific stuff into
c-torture/{compile,execute}/ieee
jeff
