Message ID | 20180705234517.6059-1-jimw@sifive.com |
---|---|
State | New |
Headers | show |
Series | [Ada] Makefile patches from initial RISC-V cross/native build. | expand |
> These are some patches I needed to complete my cross build of a native > riscv linux Ada compiler. Some paths were different on the build machine > and host machine. I needed to pass options into gnatmake to work around this, > and that required fixing some makefile rules to use $(GNATMAKE) instead of > calling gnatmake directly. > > Tested with native riscv-linux bootstrap with Ada enabled. > > OK? OK, thanks. > Jim > > gcc/ada/ > * Make-generated.in (treeprs.ads): Use $(GNATMAKE) instead of > gnatmake. > (einfo.h, sinfo.h, stamp-snames, stamp-nmake): Likewise. > * gcc-interface/Makefile.in (xoscons): Likewise.
On Fri, Jul 6, 2018 at 12:18 AM, Arnaud Charlet <charlet@adacore.com> wrote: >> These are some patches I needed to complete my cross build of a native >> riscv linux Ada compiler. Some paths were different on the build machine >> and host machine. I needed to pass options into gnatmake to work around this, >> and that required fixing some makefile rules to use $(GNATMAKE) instead of >> calling gnatmake directly. >> >> Tested with native riscv-linux bootstrap with Ada enabled. >> >> OK? > > OK, thanks. > >> Jim >> >> gcc/ada/ >> * Make-generated.in (treeprs.ads): Use $(GNATMAKE) instead of >> gnatmake. >> (einfo.h, sinfo.h, stamp-snames, stamp-nmake): Likewise. >> * gcc-interface/Makefile.in (xoscons): Likewise. Committed. Jim
On Jul 05 2018, Jim Wilson <jimw@sifive.com> wrote:
> Tested with native riscv-linux bootstrap with Ada enabled.
I'm getting a lot of errors from the assembler "non-constant .uleb128 is
not supported" when trying to bootstrap the compiler with the
cross-compiled ada compiler.
Andreas.
On Sat, Jul 7, 2018 at 12:25 AM, Andreas Schwab <schwab@linux-m68k.org> wrote: > On Jul 05 2018, Jim Wilson <jimw@sifive.com> wrote: > >> Tested with native riscv-linux bootstrap with Ada enabled. > > I'm getting a lot of errors from the assembler "non-constant .uleb128 is > not supported" when trying to bootstrap the compiler with the > cross-compiled ada compiler. GCC configure assumes that if you have gas, then non-constant .uleb128 is OK. However, because RISC-V deletes instructions at link time, we cannot allow some forms of this construct. If you have a working gas available at gcc configure time, then it should do a gas run-time test and discover that this gas feature does not work. If you do not have a working gas at gcc configure time, it will assume the feature is available, try to use it, and then you get a build failure due to gas errors. The only time I've ever seen this error is if I try to use an old-style combined-tree build approach, because in this case gcc configures before gas is built. If you build and install binutils, and then build and install gcc, the build will work. I haven't tried to fix the old-style combined-tree approach, I didn't see an obvious fix, and since I don't like to do builds this way anymore it wasn't important enough to me to try to fix. JIm
On Jul 07 2018, Jim Wilson <jimw@sifive.com> wrote: > If you build and install binutils, and then build and install gcc, the > build will work. Not if the compiler was built in a canadian cross. That's the only way to bootstrap an Ada compiler. Andreas.
On Sat, Jul 7, 2018 at 10:06 AM, Andreas Schwab <schwab@linux-m68k.org> wrote: > On Jul 07 2018, Jim Wilson <jimw@sifive.com> wrote: > >> If you build and install binutils, and then build and install gcc, the >> build will work. > > Not if the compiler was built in a canadian cross. That's the only way > to bootstrap an Ada compiler. It worked for me. I have RISC-V Fedora Linux Ada compiler binaries that I built cross from an x86_64 Ubuntu 18.04 system. You should only see the gas error if your gas sources are in the same source tree as your gcc sources. if you have separate binutils and gcc source trees, the build should work. In the gcc/configure.ac file, see the in_tree_gas and in_tree_gas_elf variables, which are set if gas/ELF gas are in the same source tree. And then look at configure, and note that configure makes assumptions about gas features when these variables are set, instead of doing run-time assembler checks. I've done number of canadian cross compiler builds, and I've never run into this gas problem in any of them, but I always use separate binutils and gcc source trees for my builds. Jim
On Jul 07 2018, Jim Wilson <jimw@sifive.com> wrote: > You should only see the gas error if your gas sources are in the same > source tree as your gcc sources. Nope. > if you have separate binutils and gcc source trees, the build should > work. It's not the canadian cross build that fails, but the subsequent native build using the (misconfigured) canadian cross build. Andreas.
On Sat, Jul 7, 2018 at 11:30 AM, Andreas Schwab <schwab@linux-m68k.org> wrote: > On Jul 07 2018, Jim Wilson <jimw@sifive.com> wrote: >> if you have separate binutils and gcc source trees, the build should >> work. > > It's not the canadian cross build that fails, but the subsequent native > build using the (misconfigured) canadian cross build. This works for me. I have a sysroot created from a live system. I configure/build/install a cross binutils, then cross gcc. I put the cross install tree on my path, then I configure/build/install the canadian cross binutils and then gcc. Then I copy the canadian cross install tree to the RISC-V system and use it to bootstrap a native gcc with Ada. This is also presumably what the debian, fedora, and gentoo folks did to get their first native compiler. They didn't report any problems. Is this the first time you are trying to build a native RISC-V compiler for OpenSuse? If you already built a C/C++ compiler, then I would expect the Ada compiler build to work the same way. But if this is your first native RISC-V compiler build attempt then maybe there is something different about how you are trying to do the build. I could share my build scripts with you but they are pretty simple. It is also possible to build a canadian cross compiler from github riscv/riscv-gnu-toolchain using the linux-native makefile rule, but since it has its own copy of glibc you might run into glibc versioning problems. One thing I could mention is that I started with a gcc-7.3 release, because Ubuntu 18.04 has gcc-7.3 as the native compiler, and I wasn't sure if gcc-7 Ada could build gcc-9 Ada. Sometimes old Ada versions can't compile new Ada versions. So I actually did the canadian cross build with binutils-2.30 and gcc-7.3.1, and then moved up from gcc-7 to gcc-9 on the RISC-V side. I maybe haven't tried a canadian cross build with a newer gcc version, so maybe something broke after gcc-7. That seems unlikely though. If you can give me details about exactly how you are trying to canadian cross build the Ada compiler, I can try to reproduce your problem here. Jim
On Jul 07 2018, Jim Wilson <jimw@sifive.com> wrote: > This is also presumably what the debian, fedora, and gentoo folks did > to get their first native compiler. They didn't report any problems. Of course, they didn't build an ada compiler. > Is this the first time you are trying to build a native RISC-V > compiler for OpenSuse? I have bootstrapped several architectures for SUSE and openSUSE, thank you. Andreas.
On Sat, Jul 7, 2018 at 2:43 PM, Andreas Schwab <schwab@linux-m68k.org> wrote: > On Jul 07 2018, Jim Wilson <jimw@sifive.com> wrote: > >> This is also presumably what the debian, fedora, and gentoo folks did >> to get their first native compiler. They didn't report any problems. > > Of course, they didn't build an ada compiler. But building an Ada compiler works exactly the same as building C and C++ compilers. There should really be no difference. >> Is this the first time you are trying to build a native RISC-V >> compiler for OpenSuse? > > I have bootstrapped several architectures for SUSE and openSUSE, thank > you. I am aware that you have much experience building stuff. But building RISC-V is a little different than the others, because of link-time relaxations deleting code, which means some things that work for other targets don't work for RISC-V. It is possible that the scheme you are using to build canadian cross compilers will work for other targets but not RISC-V because of this problem. That is why I asked if this is your first attempt to canadian cross build a RISC-V native compiler. And because of the above, that building Ada should be no different from building C and C++. Anyways, all I can repeat is what I've said before. It works for me. I can give you my trivial build scripts if you want. Otherwise, you have to give me enough info that I can reproduce the problem that you ran into. Jim
On Jul 07 2018, Jim Wilson <jimw@sifive.com> wrote: > But building an Ada compiler works exactly the same as building C and > C++ compilers. There should really be no difference. That Ada compiler is unique in that it uses exceptions. Andreas.
Hello Jim, On 07/06/2018 01:45 AM, Jim Wilson wrote: > These are some patches I needed to complete my cross build of a native > riscv linux Ada compiler. Some paths were different on the build machine > and host machine. I needed to pass options into gnatmake to work around this, > and that required fixing some makefile rules to use $(GNATMAKE) instead of > calling gnatmake directly. At AdaCore, we realized that this patch broke our canadian builds: in the cases your patch involved, the intent is to call the build toolchain, not the host one (to which GNATMAKE expands to). Given that you described this change as a workaround for cross-machine path issues, I was wondering: do you still need this? If not, we should probably revert it right now, otherwise we should investigate why you needed it in the first place. What do you think?
On Thu, Aug 2, 2018 at 1:44 AM, Pierre-Marie de Rodat <derodat@adacore.com> wrote: > On 07/06/2018 01:45 AM, Jim Wilson wrote: >> >> These are some patches I needed to complete my cross build of a native >> riscv linux Ada compiler. Some paths were different on the build machine >> and host machine. I needed to pass options into gnatmake to work around >> this, >> and that required fixing some makefile rules to use $(GNATMAKE) instead of >> calling gnatmake directly. > > > At AdaCore, we realized that this patch broke our canadian builds: in the > cases your patch involved, the intent is to call the build toolchain, not > the host one (to which GNATMAKE expands to). > > Given that you described this change as a workaround for cross-machine path > issues, I was wondering: do you still need this? If not, we should probably > revert it right now, otherwise we should investigate why you needed it in > the first place. What do you think? I only needed it for the first canadian cross build. If it is causing problems for you it can be dropped. If I need it again, it is easy enough to write again. I ran into a problem where the search paths were wrong when running the canadian cross built compiler for the native build, and I had to add something like -cargs -L$installdir/lib to gnatmake to make it work, but it is possible I did something wrong. These canadian cross builds aren't something I do often, so I might have made a mistake. Also, RISC-V is a new target, so there are lots of things that are just a little broken and have to be worked around. This might have been related to one of those problems. Jim
On 08/02/2018 04:44 PM, Jim Wilson wrote: > I only needed it for the first canadian cross build. If it is causing > problems for you it can be dropped. If I need it again, it is easy > enough to write again. Ok, thank you! I’ve just committed the revert. > I ran into a problem where the search paths were wrong when running > the canadian cross built compiler for the native build, and I had to > add something like -cargs -L$installdir/lib to gnatmake to make it > work, but it is possible I did something wrong. These canadian cross > builds aren't something I do often, so I might have made a mistake. > Also, RISC-V is a new target, so there are lots of things that are > just a little broken and have to be worked around. This might have > been related to one of those problems. Understood, thank you for the context. Let’s try to fix the underlying problem if you have issues with canadian crosses again. :-)
On Aug 03 2018, Pierre-Marie de Rodat <derodat@adacore.com> wrote: > Understood, thank you for the context. Let’s try to fix the underlying > problem if you have issues with canadian crosses again. :-) There should at least be a way to find the build gnatmake under a different name. Andreas.
diff --git a/gcc/ada/Make-generated.in b/gcc/ada/Make-generated.in index 757eaa85b90..bdcb62c4e56 100644 --- a/gcc/ada/Make-generated.in +++ b/gcc/ada/Make-generated.in @@ -28,21 +28,21 @@ $(ADA_GEN_SUBDIR)/treeprs.ads : $(ADA_GEN_SUBDIR)/treeprs.adt $(ADA_GEN_SUBDIR)/ -$(MKDIR) $(ADA_GEN_SUBDIR)/bldtools/treeprs $(RM) $(addprefix $(ADA_GEN_SUBDIR)/bldtools/treeprs/,$(notdir $^)) $(CP) $^ $(ADA_GEN_SUBDIR)/bldtools/treeprs - (cd $(ADA_GEN_SUBDIR)/bldtools/treeprs; gnatmake -q xtreeprs ; ./xtreeprs treeprs.ads ) + (cd $(ADA_GEN_SUBDIR)/bldtools/treeprs; $(GNATMAKE) -q xtreeprs ; ./xtreeprs treeprs.ads ) $(MOVE_IF_CHANGE) $(ADA_GEN_SUBDIR)/bldtools/treeprs/treeprs.ads $(ADA_GEN_SUBDIR)/treeprs.ads $(ADA_GEN_SUBDIR)/einfo.h : $(ADA_GEN_SUBDIR)/einfo.ads $(ADA_GEN_SUBDIR)/einfo.adb $(ADA_GEN_SUBDIR)/xeinfo.adb $(ADA_GEN_SUBDIR)/ceinfo.adb -$(MKDIR) $(ADA_GEN_SUBDIR)/bldtools/einfo $(RM) $(addprefix $(ADA_GEN_SUBDIR)/bldtools/einfo/,$(notdir $^)) $(CP) $^ $(ADA_GEN_SUBDIR)/bldtools/einfo - (cd $(ADA_GEN_SUBDIR)/bldtools/einfo; gnatmake -q xeinfo ; ./xeinfo einfo.h ) + (cd $(ADA_GEN_SUBDIR)/bldtools/einfo; $(GNATMAKE) -q xeinfo ; ./xeinfo einfo.h ) $(MOVE_IF_CHANGE) $(ADA_GEN_SUBDIR)/bldtools/einfo/einfo.h $(ADA_GEN_SUBDIR)/einfo.h $(ADA_GEN_SUBDIR)/sinfo.h : $(ADA_GEN_SUBDIR)/sinfo.ads $(ADA_GEN_SUBDIR)/sinfo.adb $(ADA_GEN_SUBDIR)/xsinfo.adb $(ADA_GEN_SUBDIR)/csinfo.adb -$(MKDIR) $(ADA_GEN_SUBDIR)/bldtools/sinfo $(RM) $(addprefix $(ADA_GEN_SUBDIR)/bldtools/sinfo/,$(notdir $^)) $(CP) $^ $(ADA_GEN_SUBDIR)/bldtools/sinfo - (cd $(ADA_GEN_SUBDIR)/bldtools/sinfo; gnatmake -q xsinfo ; ./xsinfo sinfo.h ) + (cd $(ADA_GEN_SUBDIR)/bldtools/sinfo; $(GNATMAKE) -q xsinfo ; ./xsinfo sinfo.h ) $(MOVE_IF_CHANGE) $(ADA_GEN_SUBDIR)/bldtools/sinfo/sinfo.h $(ADA_GEN_SUBDIR)/sinfo.h $(ADA_GEN_SUBDIR)/snames.h $(ADA_GEN_SUBDIR)/snames.ads $(ADA_GEN_SUBDIR)/snames.adb : $(ADA_GEN_SUBDIR)/stamp-snames ; @true @@ -50,7 +50,7 @@ $(ADA_GEN_SUBDIR)/stamp-snames : $(ADA_GEN_SUBDIR)/snames.ads-tmpl $(ADA_GEN_SUB -$(MKDIR) $(ADA_GEN_SUBDIR)/bldtools/snamest $(RM) $(addprefix $(ADA_GEN_SUBDIR)/bldtools/snamest/,$(notdir $^)) $(CP) $^ $(ADA_GEN_SUBDIR)/bldtools/snamest - (cd $(ADA_GEN_SUBDIR)/bldtools/snamest; gnatmake -q xsnamest ; ./xsnamest ) + (cd $(ADA_GEN_SUBDIR)/bldtools/snamest; $(GNATMAKE) -q xsnamest ; ./xsnamest ) $(MOVE_IF_CHANGE) $(ADA_GEN_SUBDIR)/bldtools/snamest/snames.ns $(ADA_GEN_SUBDIR)/snames.ads $(MOVE_IF_CHANGE) $(ADA_GEN_SUBDIR)/bldtools/snamest/snames.nb $(ADA_GEN_SUBDIR)/snames.adb $(MOVE_IF_CHANGE) $(ADA_GEN_SUBDIR)/bldtools/snamest/snames.nh $(ADA_GEN_SUBDIR)/snames.h @@ -61,7 +61,7 @@ $(ADA_GEN_SUBDIR)/stamp-nmake: $(ADA_GEN_SUBDIR)/sinfo.ads $(ADA_GEN_SUBDIR)/nma -$(MKDIR) $(ADA_GEN_SUBDIR)/bldtools/nmake $(RM) $(addprefix $(ADA_GEN_SUBDIR)/bldtools/nmake/,$(notdir $^)) $(CP) $^ $(ADA_GEN_SUBDIR)/bldtools/nmake - (cd $(ADA_GEN_SUBDIR)/bldtools/nmake; gnatmake -q xnmake ; ./xnmake -b nmake.adb ; ./xnmake -s nmake.ads) + (cd $(ADA_GEN_SUBDIR)/bldtools/nmake; $(GNATMAKE) -q xnmake ; ./xnmake -b nmake.adb ; ./xnmake -s nmake.ads) $(MOVE_IF_CHANGE) $(ADA_GEN_SUBDIR)/bldtools/nmake/nmake.ads $(ADA_GEN_SUBDIR)/nmake.ads $(MOVE_IF_CHANGE) $(ADA_GEN_SUBDIR)/bldtools/nmake/nmake.adb $(ADA_GEN_SUBDIR)/nmake.adb touch $(ADA_GEN_SUBDIR)/stamp-nmake diff --git a/gcc/ada/gcc-interface/Makefile.in b/gcc/ada/gcc-interface/Makefile.in index 9a52e6d8edb..601f23afc1c 100644 --- a/gcc/ada/gcc-interface/Makefile.in +++ b/gcc/ada/gcc-interface/Makefile.in @@ -613,7 +613,7 @@ OSCONS_EXTRACT=$(OSCONS_CC) $(GNATLIBCFLAGS_FOR_C) -S s-oscons-tmplt.i -$(MKDIR) ./bldtools/oscons $(RM) $(addprefix ./bldtools/oscons/,$(notdir $^)) $(CP) $^ ./bldtools/oscons - (cd ./bldtools/oscons ; gnatmake -q xoscons) + (cd ./bldtools/oscons ; $(GNATMAKE) -q xoscons) $(RTSDIR)/s-oscons.ads: ../stamp-gnatlib1-$(RTSDIR) s-oscons-tmplt.c gsocket.h ./bldtools/oscons/xoscons $(RM) $(RTSDIR)/s-oscons-tmplt.i $(RTSDIR)/s-oscons-tmplt.s