Is anyone working on a Z80 port?
Hi, Thought I'd ask here as I've not managed to find any positive answers from google. But is anyone working on a Z80 port of GCC 4 or 5? I've managed to find patches for Z80 ports but they are using ancient GCC's. Thanks, Luke.
Re: Is anyone working on a Z80 port?
I forgot, I'm not interested in using C, so SDCC is out of the question. On 14/10/15 16:04, Luke A. Guest wrote: > Hi, > > Thought I'd ask here as I've not managed to find any positive answers > from google. > > But is anyone working on a Z80 port of GCC 4 or 5? > > I've managed to find patches for Z80 ports but they are using ancient GCC's. > > Thanks, > Luke. > >
Proper way to build GNAT cross compiler with gnattools
Hi, I'm trying (again) to work out how to build a GNAT cross compiler with no runtime, but with the tools. Firstly, I'd just like to ask, is this supposed to be possible? If it is possible, why is it so hard/impossible and why will nobody from AdaCore answer my questions regarding it? I'm wanting to start development on my kernel and would prefer not to use a hacky way to do it. I'm currently using binutils-2.21, newlib-1.19.0, gcc-4.5.2, latest mpfr, bmp, mpc and am trying to target arm-none-eabi to start with. I've firstly build binutils, then gcc C compiler, then newlib, now i'm trying to build C + Ada. I need the C stuff with newlib so I can build u-boot, but when I get to Ada, I don't need it at all. I'm configuring the second gcc build with: ../../../src/gcc-$GCC_VERSION/configure \ --prefix=$PREFIX \ --target=$1 \ $2 \ --enable-multilib \ --with-newlib \ --with-headers=../../../src/newlib-$NEWLIB_VERSION/newlib/libc/include \ --disable-nls \ --disable-shared \ --disable-threads \ --with-gnu-as \ --with-gnu-ld \ --enable-languages=c,ada \ --disable-libssp \ --disable-libada \ --with-gmp=$GCC_LIBS_PREFIX/gmp \ --with-mpfr=$GCC_LIBS_PREFIX/mpfr \ --with-mpc=$GCC_LIBS_PREFIX/mpc &> log.config.txt $1 is arm-none-eabi and $2 is the --enable-interworking passed as parameters to my build function. When I do a "make" it fails around here: make[2]: Leaving directory `/home/laguest/src/mine/tamp/thirdparty/build/arm-none-eabi/gcc2/gcc' mkdir -p -- ./gnattools Configuring in ./gnattools configure: creating cache ./config.cache checking for a BSD-compatible install... /usr/bin/install -c checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu checking target system type... arm-none-eabi checking whether ln -s works... yes checking for x86_64-unknown-linux-gnu-gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed configure: updating cache ./config.cache configure: creating ./config.status config.status: creating Makefile make[2]: Entering directory `/home/laguest/src/mine/tamp/thirdparty/build/arm-none-eabi/gcc2/gnattools' rm -rf ../gcc/ada/tools mkdir -p ../gcc/ada/tools (cd ../gcc/ada/tools; ln -s ../sdefault.adb ../snames.ads ../snames.adb .) touch ../gcc/stamp-tools # gnattools1-re make -C ../gcc/ada/tools -f ../Makefile \ "CC=gcc" "CFLAGS=-g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes" "LDFLAGS=" "ADAFLAGS=-gnatpg -gnata" "ADA_CFLAGS=" "INCLUDES=-I. -I.. -I../.. -I/home/laguest/src/mine/tamp/thirdparty/src/gcc-4.5.2/gcc/ada -I/home/laguest/src/mine/tamp/thirdparty/src/gcc-4.5.2/gcc/config -I/home/laguest/src/mine/tamp/thirdparty/src/gcc-4.5.2/gcc/../include -I/home/laguest/src/mine/tamp/thirdparty/src/gcc-4.5.2/gcc" "ADA_INCLUDES=-I/usr/lib/gcc/x86_64-linux-gnu/4.4.3/adalib/../adainclude -I/usr/lib/gcc/x86_64-linux-gnu/4.4.3/adalib/ -I. -I/home/laguest/src/mine/tamp/thirdparty/src/gcc-4.5.2/gcc/ada" "exeext=" "fsrcdir=/home/laguest/src/mine/tamp/thirdparty/src/gcc-4.5.2/gcc" "srcdir=/home/laguest/src/mine/tamp/thirdparty/src/gcc-4.5.2/gcc" "GNATMAKE=gnatmake" "GNATLINK=gnatlink" "GNATBIND=gnatbind" "TOOLSCASE=cross" "LIBGNAT=" INCLUDES="" \ gnatmake-re gnatlink-re make[3]: Entering directory `/home/laguest/src/mine/tamp/thirdparty/build/arm-none-eabi/gcc2/gcc/ada/tools' gcc -c -DCROSS_DIRECTORY_STRUCTURE -DIN_GCC `echo -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes |sed -e 's/-pedantic//g' -e 's/-Wtraditional//g'` \ /home/laguest/src/mine/tamp/thirdparty/src/gcc-4.5.2/gcc/ada/link.c -o link.o gcc -c -DCROSS_DIRECTORY_STRUCTURE -DIN_GCC `echo -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes |sed -e 's/-pedantic//g' -e 's/-Wtraditional//g'` \ -I. -I.. -I../.. -I/home/laguest/src/mine/tamp/thirdparty/src/gcc-4.5.2/gcc/ada -I/home/laguest/src/mine/tamp/thirdparty/src/gcc-4.5.2/gcc/../include -I/home/laguest/src/mine/tamp/thirdparty/src/gcc-4.5.2/gcc \ /home/laguest/src/mine/tamp/thirdparty/src/gcc-4.5.2/gcc/ada/targext.c -o targext.o gnatmake -I/usr/lib/gcc/x86_64-linux-gnu/4.4.3/adalib/../adainclude -I/usr/lib/gcc/x86_64-linux-gnu/4.4.3/adalib/ -I. -I/home/laguest/src/mine/tamp/thirdparty/src/gcc-4.5.2/gcc/ada -u sdefault --GCC="gcc " gcc -c -I/usr/lib/gcc/x86_64-linux-gnu/4.4.3/adalib/../adainclude -I/usr/lib/gcc/x86_64-linux-gnu/4.4.3/adalib/ -I. -I/home/laguest/src/mine/tamp/thirdparty/src/gcc-4.5.2/gcc/ada sdefault.adb gnatmake -c -I/usr/lib/gcc/x86_64-linux-gnu/4.4.3/adalib/../adainclude -I/usr/lib/gcc/x86_64-linux-gnu/4.4.3/adalib/ -I. -I/home/laguest/src/mine/tamp/thirdparty/src/gcc-4.5.2/gcc/ada gnatmake --GCC="gcc -g -O2 -
Re: Proper way to build GNAT cross compiler with gnattools
On Tue, 2011-02-01 at 18:57 +0100, Arnaud Charlet wrote: > > I'm trying (again) to work out how to build a GNAT cross compiler with > > no runtime, but with the tools. > > As explained in the documentation, you need to first build a native GNAT > compiler with the same sources before building a GNAT cross compiler. Ok, I can't find it. I'just grepped for cross and compi through gcc/ada/*.texi and there are references, but nothing that you state. Certainly not in the fsf 4.5.2 version of gnat. I also cannot see anything obvious in the gnat pro docs that I've managed to find online. Can you point me at least to the section which explains this? Thanks, Luke.
ARM EABI ZCX Ada (4.6.1) almost working
Hi, I managed to debug the my sample app and find an error, which has made catching an exception work. Anyway, I changed the code to throw an exception in a nested subprogram, this was also caught by the outer subprogram. I then added a raise; statement as a handler to see if it would reraise and then exit the program, sadly, I get an infinite loop in the search phase (export EH_DEBUG=1 shows this). I've included the latest patch which gets the basics working. But I'm lost as to why it's not working for the reraise case. Can anyone help? Thanks, Luke. ** Just for info, so it's documented somewhere ** Just for people who need to know (as I couldn't find it anywhere), to get gnatlib to build with debugging info, I used the following: make -e GNATLIBCFLAGS='-ggdb -O0' This is then picked up the gcc/ada makefiles later in the build. diff -x '*~' -uNr gcc-4.6.1.orig/gcc/ada/a-exexpr-gcc.adb gcc-4.6.1/gcc/ada/a-exexpr-gcc.adb --- gcc-4.6.1.orig/gcc/ada/a-exexpr-gcc.adb 2009-04-09 16:00:19.0 +0100 +++ gcc-4.6.1/gcc/ada/a-exexpr-gcc.adb 2011-10-07 02:30:41.0 +0100 @@ -35,87 +35,11 @@ with Ada.Unchecked_Deallocation; with System.Storage_Elements; use System.Storage_Elements; +with System.Exception_Unwind; use System.Exception_Unwind; separate (Ada.Exceptions) package body Exception_Propagation is - - -- Entities to interface with the GCC runtime -- - - - -- These come from "C++ ABI for Itanium: Exception handling", which is - -- the reference for GCC. They are used only when we are relying on - -- back-end tables for exception propagation, which in turn is currently - -- only the case for Zero_Cost_Exceptions in GNAT5. - - -- Return codes from the GCC runtime functions used to propagate - -- an exception. - - type Unwind_Reason_Code is - (URC_NO_REASON, - URC_FOREIGN_EXCEPTION_CAUGHT, - URC_PHASE2_ERROR, - URC_PHASE1_ERROR, - URC_NORMAL_STOP, - URC_END_OF_STACK, - URC_HANDLER_FOUND, - URC_INSTALL_CONTEXT, - URC_CONTINUE_UNWIND); - - pragma Unreferenced - (URC_FOREIGN_EXCEPTION_CAUGHT, - URC_PHASE2_ERROR, - URC_PHASE1_ERROR, - URC_NORMAL_STOP, - URC_END_OF_STACK, - URC_HANDLER_FOUND, - URC_INSTALL_CONTEXT, - URC_CONTINUE_UNWIND); - - pragma Convention (C, Unwind_Reason_Code); - - -- Phase identifiers - - type Unwind_Action is - (UA_SEARCH_PHASE, - UA_CLEANUP_PHASE, - UA_HANDLER_FRAME, - UA_FORCE_UNWIND); - - for Unwind_Action use - (UA_SEARCH_PHASE => 1, - UA_CLEANUP_PHASE => 2, - UA_HANDLER_FRAME => 4, - UA_FORCE_UNWIND => 8); - - pragma Convention (C, Unwind_Action); - - -- Mandatory common header for any exception object handled by the - -- GCC unwinding runtime. - - type Exception_Class is mod 2 ** 64; - - GNAT_Exception_Class : constant Exception_Class := 16#474e552d41646100#; - -- "GNU-Ada\0" - - type Unwind_Word is mod 2 ** System.Word_Size; - for Unwind_Word'Size use System.Word_Size; - -- Map the corresponding C type used in Unwind_Exception below - - type Unwind_Exception is record - Class: Exception_Class := GNAT_Exception_Class; - Cleanup : System.Address := System.Null_Address; - Private1 : Unwind_Word; - Private2 : Unwind_Word; - end record; - -- Map the GCC struct used for exception handling - - for Unwind_Exception'Alignment use Standard'Maximum_Alignment; - -- The C++ ABI mandates the common exception header to be at least - -- doubleword aligned, and the libGCC implementation actually makes it - -- maximally aligned (see unwind.h). See additional comments on the - -- alignment below. - -- -- GNAT Specific Entities To Deal With The GCC EH Circuitry -- -- diff -x '*~' -uNr gcc-4.6.1.orig/gcc/ada/ChangeLog gcc-4.6.1/gcc/ada/ChangeLog --- gcc-4.6.1.orig/gcc/ada/ChangeLog 2011-06-27 11:03:04.0 +0100 +++ gcc-4.6.1/gcc/ada/ChangeLog 2011-10-09 11:51:05.0 +0100 @@ -1,3 +1,18 @@ +2011-10-09 Luke A. Guest + + * Initial port of ZCX code to ARM Linux. + * s-excunw-gcc.ads: New file, extracts the normal GCC Unwind_Exception + into it's own package. + * s-excunw-gcc-arm.ads: New file, extracts the ARM EABI GCC + Unwind_Exception into it's own package. + * a-exexpr-gcc.adb: Unwind_Exception and other enumerations removed. + * gcc-interface/Makefile.in: Handle new files to build for native and + ARM EABI exception blocks. + * Makefile.rtl: Added a line to build above unwind exception package. + * raise-gcc.c: Added support for ARM EABI UNWINDER. + * system-linux-armeb.ads: Changed to support
Re: ARM EABI ZCX Ada (4.6.1) almost working
On Sun, 2011-10-09 at 20:38 +0100, Luke A. Guest wrote: > Anyway, I changed the code to throw an exception in a nested subprogram, > this was also caught by the outer subprogram. I then added a raise; > statement as a handler to see if it would reraise and then exit the > program, sadly, I get an infinite loop in the search phase (export > EH_DEBUG=1 shows this). On further thinking about this, I have a feeling this may have something to do with the Private1 field of the unwind_exception, but I'm not too sure how yet. Luke.
Re: ARM EABI ZCX Ada (4.6.1) almost working
On Wed, 2011-10-12 at 09:09 +0200, Eric Botcazou wrote: > > On further thinking about this, I have a feeling this may have something > > to do with the Private1 field of the unwind_exception, but I'm not too > > sure how yet. > > For sure, adding a couple of fields on the Ada side that don't exist on the C > side is highly suspicious. Better get rid of them in any case I'd think. Aye, then the Ada side doesn't build. Can you see what it is I'm missing? I can't say I truly understand this code, especially that in raise-gcc.c. I do understand there are 2 phases, but I have to say the code as the documentation (even where there is docs) is still very cryptic. I'm beginning to think the whole of a-exexpr-gcc needs to be extracted into 2 distinct files, a-exexpr-gcc (normal GCC EH - as it is) and a-exexpr-gcc-arm (ARM EABI EH). Thanks, Luke.
Re: Minimum required GNAT version for bootstrap of GNAT on gcc trunk
I managed to build it with my own compiled version of GCC-4.3 under Ubuntu. The stock 4.1 compilers failed on a -f flag IIRC, can't remember what it was exactly though. Luke.
Porting ZCX (not SJLJ) for GNAT ARM EABI
Hi, I'm having a look into getting DWARF2 exceptions (ZCX) working on ARM. I just wondered if anyone has done this yet or is working on it? My target will be N900 Maemo, I'll have to use an older GCC due to the fact that the ABI changed at v4.4 (http://gcc.gnu.org/gcc-4.4/changes.html bit-fields). So I'll probably take the CodeSourcery GCC sources and use that to start with. I'll be trying to get it to work under MADDE as Scratchbox is harder to work with. I'm not 100% sure how to get it to compile yet though. Any pointers would be gratefully received. I'm fairly sure I know where to start. Thanks, Luke.
Re: Porting ZCX (not SJLJ) for GNAT ARM EABI
On Fri, 2010-09-24 at 15:39 -0700, Andrew Pinski wrote: > > (http://gcc.gnu.org/gcc-4.4/changes.html bit-fields). > > > That ABI change only structs which are marked as being packed. If you > have some of those in your code, you need to understand that before > 4.4, it was incorrectly working. Yup, was meaning to do a grep on the sysroot in MADDE to see where the __attribute__ ((packed)) was used, seems there are no bitfields there, so should be fine with a later GCC :D Thanks, Luke.
Re: Porting ZCX (not SJLJ) for GNAT ARM EABI
On Mon, 2010-09-27 at 11:12 +0200, Olivier Hainque wrote: > Hello Luke, > > Luke A. Guest wrote: > > I'm having a look into getting DWARF2 exceptions (ZCX) working on ARM. > > Thanks :-) Well, I'm reading as much as I can regarding this, but finding it hard to work some things out. I've been reading through: http://gcc.gnu.org/ml/gcc/2004-03/msg01779.html and trying some example code in C++ and Ada, but it doesn't seem to match up in some places, i.e. no calls into __register_frame_info() yet the libgcc_eh.so contains the function. > > Any pointers would be gratefully received. I'm fairly sure I know where > > to start. > > A few general points, jic. > > The first thing will be to adjust your target system.ads to > have GCC_ZCX_Support := True, then use the gnatlib-zcx Makefile > target, with essentially two effects: adjust your target system.ads > further to switch the GCC_ZCX_Support to True as well, and arrange > to build/link with the "-gcc" variants of a-exexpr.adb and raise.c. Yup, aware of this so far. > The system.ads changes control the compiler to declare eh regions, produce > dwarf eh info etc. Yup. > The use of -gcc variants is for the runtime library, switching to the > libgcc services for exception propagations. > > raise-gcc.c hosts the Ada personality routine, where a number of changes > will be needed I believe. Also, I think tracebak.c is where the ARM specific routine(s) will need to go, included from another file tb-armlinux.c? I think this will be required as (if I'm right), different ARM CPU's have differing number of registers, and I think I read in the ARM docs that float regs won't need to be saved if they're not used. I could be wrong about this though. > There, please, I'd rather have the ARM specializations abstracted as > much as possible, e.g. with new functions and alternate implementations, > instead of provided as #ifdefs blocks spread within existing functions. Well, I think that's possible to a point, obviously some things will have to go into ifdef's unfortunately (it's not Ada :D). Hopefully, I can rely on some help from you AdaCore guys? This is my first foray into GCC internals :/ Thanks, Luke.
Re: Porting ZCX (not SJLJ) for GNAT ARM EABI
On Mon, 2010-09-27 at 12:33 +0200, Olivier Hainque wrote: > Luke A. Guest wrote: > > Well, I'm reading as much as I can regarding this, but finding it hard > > to work some things out. > > That's a pretty complex and very precise machinery overall. You're not wrong. > > I've been reading through: > > http://gcc.gnu.org/ml/gcc/2004-03/msg01779.html and trying some example > > code in C++ and Ada, but it doesn't seem to match up in some places, > > i.e. no calls into __register_frame_info() yet the libgcc_eh.so contains > > the function. > > There's a variety of registration functions and some targets > don't resort to such calls at all, see unwind-dw2-fde-glibc.c. > > A quick glance suggests that your arm-linux port might be using the > latter (from t-linux if I'm not mistaken, I'm not at all familiar with > the port though). I can't see any mention of unwind in the the t-linux-eabi file, I'm probably missing something I just don't unerstand here :D > While I know there are arm-eabi specifics wrt unwinding, I'm really > not familiar with the details so I'm not sure what exactly will be > needed for traceback computations. > > Wouldn't tb-gcc.c "just work" (using _Unwind_Backtrace) ? I would expect so, but again, not sure on this yet. > especially when that needs to be repeated in several places. Fair enough. > > Hopefully, I can rely on some help from you AdaCore guys? > > Some, sure :) As I said we aren't familiar with the details of the ARM > EH specifics and we're not running arm-linux in-house, so ... > > Now if you get something working, we can comment on the integration > scheme for the Ada specific parts. Ok. > > This is my first foray into GCC internals :/ > > Welcome :-D > > Out of curiosity, why did you choose that particular topic (ZCX for > Ada on arm-linux) ? Does this just happen to seem of interest for > learning purposes, or is there a more specific need ? In #Ada there are always people coming in and asking if there is an ARM GNAT, which we always say "sort of..." ARM CPU's aren't the fastest on the planet and not having EABI EH to help with this is something that really needs to be done imho. Also, with the ever increasing number of ARM CPU's out there, having Ada on them would useful (if only to a few of us). It makes sense to me that a language which was designed for embedded use, doesn't get much embedded use :/ in the mainstream. Thanks, Luke.
GNAT ARM EABI ZCX, possible stopper needs clarification
Hi, I've been reading as much as possible and trying to follow the source as much as possible and have, I think, come across a bit of a stopper as it may require a re-arrangement of GNAT sources, if I'm right, that is. So an exception object is defined within a-exexpr-gcc.adb as: type Unwind_Exception is record Class: Exception_Class := GNAT_Exception_Class; Cleanup : System.Address := System.Null_Address; Private1 : Unwind_Word; Private2 : Unwind_Word; end record; This maps onto the C structure for DWARF2 exceptions. GNAT then defines it's language specific record: type GNAT_GCC_Exception is record Header : Unwind_Exception; -- ABI Exception header first Id : Exception_Id; ... etc. ... end record; With it's extra fields tagged onto the end. No problem there. The ARM EABI code has it's own unwinder library defined within gcc/config/arm/unwind-arm.[ch]. When _Unwind_RaiseException is called, a stub in libunwind.S is called which sets up an extra parameter for the Virtual Register Set (VRS) data and then calls the __gnu_Unwind_RaiseException which was a _Unwind_Control_Block as a first parameter. All the other API functions are handled similarly. Within unwind-arm.h this line is defined: #define _Unwind_Exception _Unwind_Control_Block >From what I can tell, the _Unwind_Control_Block is the _Unwind_Exception under ARM EABI, which is actually bigger than the _Unwind_Exception struct by quite a bit. This will cause a problem for GNAT as it's written in Ada, rather than C, like the other front-ends. So, if I'm correct, I need to extract Unwind_Exception from a-exexpr-gcc.adb into 2 private child packages, 1 for the ARM EABI and 1 for everything else which works normally. The ARM EABI version will then mirror the _Unwind_Control_Block defined in unwind-arm.h. Can someone verify if my assertions are correct before I do anything further? Thanks, Luke.
"Ada.Exceptions.Exception_Propagation" is not a predefined library unit
Hi, I've tried what I thought was correct and implemented 2 new private child specifications (of Ada.Exceptions.Exception_Propagation) containing the specifications of the Unwind_Exception (generic) and the Unwind_Control_Block/Unwind_Exception (ARM EABI) and I'm getting the following error and I've no idea why it's doing this. This is for the my host machine to check to see if it still builds, the ARM code isn't there yet. Can anyone give me a pointer here? I'm totally new to this :/ /home/laguest/src/others/compilers/gcc/build/./gcc/xgcc -B/home/laguest/src/others/compilers/gcc/build/./gcc/ -B/opt/gcc-4.5.1/x86_64-unknown-linux-gnu/bin/ -B/opt/gcc-4.5.1/x86_64-unknown-linux-gnu/lib/ -isystem /opt/gcc-4.5.1/x86_64-unknown-linux-gnu/include -isystem /opt/gcc-4.5.1/x86_64-unknown-linux-gnu/sys-include-c -g -O2 -fPIC -W -Wall -gnatpg -g -O1 -fno-inline \ -fno-toplevel-reorder a-except.adb -o a-except.o a-exexpr.adb:39:06: "Ada.Exceptions.Exception_Propagation" is not a predefined library unit a-exexpr.adb:39:06: "Ada.Exceptions (body)" depends on "Ada.Exceptions.Exception_Propagation (body)" a-exexpr.adb:39:06: "Ada.Exceptions.Exception_Propagation (body)" depends on "Ada.Exceptions.Exception_Propagation (spec)" compilation abandoned due to previous error make[7]: *** [a-except.o] Error 1 make[7]: Leaving directory `/home/laguest/src/others/compilers/gcc/build/gcc/ada/rts' make[6]: *** [gnatlib] Error 2 make[6]: Leaving directory `/home/laguest/src/others/compilers/gcc/build/gcc/ada' make[5]: *** [gnatlib-shared-default] Error 2 make[5]: Leaving directory `/home/laguest/src/others/compilers/gcc/build/gcc/ada' make[4]: *** [gnatlib-shared-dual] Error 2 make[4]: Leaving directory `/home/laguest/src/others/compilers/gcc/build/gcc/ada' make[3]: *** [gnatlib-shared] Error 2 make[3]: Leaving directory `/home/laguest/src/others/compilers/gcc/build/gcc/ada' make[2]: *** [gnatlib-shared] Error 2 make[2]: Leaving directory `/home/laguest/src/others/compilers/gcc/build/x86_64-unknown-linux-gnu/libada' make[1]: *** [all-target-libada] Error 2 make[1]: Leaving directory `/home/laguest/src/others/compilers/gcc/build' make: *** [all] Error 2 Thanks, Luke.
Re: "Ada.Exceptions.Exception_Propagation" is not a predefined library unit
On Thu, 2010-10-14 at 09:31 +0200, Duncan Sands wrote: > Hi Luke, > > > a-exexpr.adb:39:06: "Ada.Exceptions.Exception_Propagation" is not a > > predefined library unit > > it looks like you get this error when the compiler can't find a file that it > thinks forms part of the Ada library (this is determined by the name, eg: a > package Ada.XYZ is expected to be part of the Ada library). For example, > if the compiler looks for the spec of Ada.Exceptions.Exception_Propagation > (which should be called a-exexpr.ads) but can't find it then you will get > this message. At least, that's my understanding from a few minutes of > rummaging around in the source code. Hmmm, well, this spec is actually inside the body of a-except.adb (which also specifies that the body of a-exexpr.ads is separate. All files are present in the rts dirs. Thanks, Luke.
gnattools cannot be built for freestanding/bare metal environment without hacking up the build machinery
Hi,
I've been over this before and have got nowhere with it. As I've just
retried building the latest sources after a long break I'd thought I'd
add some further comment in the hope that someone somewhere cares enough
to fix this issue; this is over my head at this time.
Say you want to build an Ada compiler for embedded work, small
SBC/micro's/osdev/whatever, you will want to set target to -elf or
similar. You can do this, to a point. You can configure the build as:
../../../source/gcc-git-ro/configure --prefix=/home/laguest/opt/tinyada
--target=arm-none-eabi --enable-interwork --enable-multilib
--without-headers --disable-nls --disable-shared --disable-threads
--disable-lto --with-gnu-as --with-gnu-ld --enable-languages=c,ada
--disable-libssp --disable-cloog-version-check
--disable-isl-version-check --with-gmp=/home/laguest/opt/tinyada
--with-mpfr=/home/laguest/opt/tinyada
--with-mpc=/home/laguest/opt/tinyada
--with-isl=/home/laguest/opt/tinyada
--with-cloog=/home/laguest/opt/tinyada
You can build it with "make all-gcc" and install with "make install-gcc"
and you get a gnat1 and -gnatbind, this is fine, you can use the
system tools, gnatmake, etc. along with these tools - I have done this
before.
But what about the gnattools? Not buildable. A message in the ml
archives states to build them with "make -C gcc gnattools," but this
fails:
make: Entering directory
`/home/laguest/src/mine/tinyada-new/build/arm-none-eabi/gcc2-built-with-git-ro/gcc'
make -C ada CC="gcc" CXX="g++" "ADA_CFLAGS=" "BISON=bison" "BISONFLAGS="
"CFLAGS=-g " "LDFLAGS=-static-libstdc++ -static-libgcc " "FLEX=flex"
"FLEXFLAGS=" "LN=ln" "LN_S=ln -s" "MAKEINFO=makeinfo
--split-size=500" "MAKEINFOFLAGS=--no-split" "MAKEOVERRIDES="
"SHELL=/bin/sh" "exeext=" "build_exeext=" "objext=.o"
"exec_prefix=/home/laguest/opt/tinyada"
"prefix=/home/laguest/opt/tinyada" "local_prefix=/usr/local"
"gxx_include_dir=/home/laguest/opt/tinyada/lib/gcc/arm-none-eabi/4.9.0/../../../../arm-none-eabi/include/c++/4.9.0"
"build_tooldir=/home/laguest/opt/tinyada/arm-none-eabi"
"gcc_tooldir=/home/laguest/opt/tinyada/lib/gcc/arm-none-eabi/4.9.0/../../../../arm-none-eabi"
"bindir=/home/laguest/opt/tinyada/bin"
"libexecsubdir=/home/laguest/opt/tinyada/libexec/gcc/arm-none-eabi/4.9.0"
"datarootdir=/home/laguest/opt/tinyada/share"
"datadir=/home/laguest/opt/tinyada/share"
"localedir=/home/laguest/opt/tinyada/share/locale" "ADA_FOR_BUILD="
"ADA_INCLUDE_DIR=/home/laguest/opt/tinyada/lib/gcc/arm-none-eabi/4.9.0/adainclude"
"ADA_RTL_OBJ_DIR=/home/laguest/opt/tinyada/lib/gcc/arm-none-eabi/4.9.0/adalib"
"ADAFLAGS=-gnatpg -gnatwns -W -Wall" "ADA_FOR_TARGET="
"INSTALL=/usr/bin/install -c" "INSTALL_DATA=/usr/bin/install -c -m 644"
"INSTALL_PROGRAM=/usr/bin/install -c"
ADA_INCLUDES="-I/home/laguest/opt/tinyada/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/adalib/../adainclude
-I/home/laguest/opt/tinyada/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/adalib/"
GNATMAKE="gnatmake" GNATBIND="gnatbind" GNATLINK="gnatlink" LIBGNAT=""
gnattools1
make[1]: Entering directory
`/home/laguest/src/mine/tinyada-new/build/arm-none-eabi/gcc2-built-with-git-ro/gcc/ada'
touch ../stamp-tools
You must first build the GNAT library: make gnatlib
make[1]: *** [../stamp-gnatlib-rts] Error 1
make[1]: Leaving directory
`/home/laguest/src/mine/tinyada-new/build/arm-none-eabi/gcc2-built-with-git-ro/gcc/ada'
make: *** [gnattools] Error 2
make: Leaving directory
`/home/laguest/src/mine/tinyada-new/build/arm-none-eabi/gcc2-built-with-git-ro/gcc'
You can't disable libada using the command line as that also disables
gnattools - I don't know the reason for requiring this behaviour.
So there are 3 ways to get this work:
1) Do what AVR-Ada (and MSP430 as they use the same patch) to knock out
the dependency of libada on gnattools, from configure:
if test "${ENABLE_LIBADA}" != "yes" ; then
noconfigdirs="$noconfigdirs"
fi
This then breaks normal builds, i.e. hosted, so you can use the same
sources reliably to build a new host compiler and the cross compiler(s).
2) Do as shown above to get gnat1 and -gnatbind and use these
through the host's system tools.
3) Patch the source up to build a custom and pointless RTS that will
just take up disk space and never get used as the user will be
implementing their own. Currently, I'm getting a bug box on my patches
for arm-none-eabi.
Given that the C compiler can be build for a freestanding environment,
as can the C++ compiler and I'm betting some of the others can too, I
can't see why the Ada compiler can't as it is supported, at least in the
source, just not in the build infrastructure.
The following (or similar) will need to be added to gnattools/configure
to enable this kind of build (under the "Per-target case statement"):
*-*-elf* | *-*-eabi*)
TOOLS_TARGET_PAIRS="\
mlib-tgt-specific.adb
Re: gnattools cannot be built for freestanding/bare metal environment without hacking up the build machinery
On Thu, 2014-01-16 at 18:53 +0100, Rolf Ebert wrote: > Am 16.01.2014 18:17, schrieb Luke A. Guest: > > > But what about the gnattools? Not buildable. A message in the ml > > archives states to build them with "make -C gcc gnattools," but this > > fails: > > This is PR19959, see comment #13. IMHO, this PR was incorrectly closed. > That's why we use the mentioned build kludge in AVR-Ada. I never liked this method, but it does work, to a point. But it is a hack. Ah, I tried looking but didn't find this, FYI http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19959 As usual, there is a comment stating, see RTEMS on how to do it, which never answers the question or fixes the issue. Also, comment 14, is the apparent howto which fails as I mentioned in my first post and I really don't understand Arnaud's comment at all there. I just don't get the reasoning. But this is not AVR specific, as he states in #16 and the following does not work either, as he states: make -C gcc gnattools-cross or make gnattools-cross as the rules don't exist, even tried -C gcc/ada. Thanks, Luke.
Re: gnattools cannot be built for freestanding/bare metal environment without hacking up the build machinery
And to clarify: $ make -C gnattools/ gnattools-cross make: Entering directory `/home/laguest/src/mine/tinyada-new/build/arm-none-eabi/gcc2-built-with-git-ro/gnattools' # gnattools1-re make -C ../gcc/ada/tools -f ../Makefile \ "CC=cc" "CXX=g++" "CFLAGS=-g -W -Wall" "LDFLAGS=" "ADAFLAGS=-gnatpg -gnata" "ADA_CFLAGS=" "INCLUDES=-I. -I.. -I../.. -I/home/laguest/src/mine/tinyada-new/source/gcc-git-ro/gcc/ada -I/home/laguest/src/mine/tinyada-new/source/gcc-git-ro/gcc/config -I/home/laguest/src/mine/tinyada-new/source/gcc-git-ro/gcc/../include -I/home/laguest/src/mine/tinyada-new/source/gcc-git-ro/gcc" "ADA_INCLUDES=-I/home/laguest/opt/tinyada/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/adalib/../adainclude -I/home/laguest/opt/tinyada/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/adalib/ -I. -I/home/laguest/src/mine/tinyada-new/source/gcc-git-ro/gcc/ada" "exeext=" "fsrcdir=/home/laguest/src/mine/tinyada-new/source/gcc-git-ro/gcc" "srcdir=/home/laguest/src/mine/tinyada-new/source/gcc-git-ro/gcc" "GNATMAKE=gnatmake" "GNATLINK=gnatlink" "GNATBIND=gnatbind" "TOOLSCASE=cross" "LIBGNAT=" INCLUDES="" \ gnatmake-re gnatlink-re make: Entering an unknown directory make: *** ../gcc/ada/tools: No such file or directory. Stop. make: Leaving an unknown directory make: *** [gnattools-cross] Error 2 make: Leaving directory `/home/laguest/src/mine/tinyada-new/build/arm-none-eabi/gcc2-built-with-git-ro/gnattools' Also fails. Luke.
Re: gnattools cannot be built for freestanding/bare metal environment without hacking up the build machinery
On Fri, 2014-02-14 at 12:11 +, Brian Drummond wrote:
> Revisiting the MSP430 as it's now an official gcc target, this is still a
> problem here too, so there are at least 3 targets for which it's a problem.
It's a problem for all targets.
> Looking at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19959
> and comparing comments #6 and #14, perhaps this command should be
> "make -C gcc gnattools-cross" ? I'll try to do a clean build and test this
> today.
>
It won't work, I've tried all those so called work arounds. They rely on
having libada built, it will complain to say that it can't be built
because there is no libada. See the attachments.
> But it would be better if the build "just worked" so at
>
> > if test "${ENABLE_LIBADA}" != "yes" ; then
> > noconfigdirs="$noconfigdirs"
> > fi
> we need a better test here (also checking for a crosscompiler build).
I have added one. It does work, sort of.
> > I think that we need a configure flag to disable libada and not
> > gnattools for these bare board targets.
>
> Following comment #15 in bug 19959, perhaps it's time to open a bug against
> --disable-libada.
The attachments allow you to configure the toolchain for bare metal, no
RTS. This flag is --enable-cross-gnattools, it checks if this is a cross
compiler and if it is, disables libada, but not gnattools.
There is an issue and I don't know why it does this, but it won't allow
you to build the gnattools straight away. You have to use:
make all-gcc
make -C gnattools/ gnattools
rm gcc/stamp-tools
make -C gcc cross-gnattools
make install-gcc
This will then build.
I have not checked to see if you can still build gcc for normal hosted
with this patch, neither have I checked to make sure --disable-libada
works in hosted either.
I have built the following with these patches:
arm-none-eabi
mips-elf
msp430-elf
x86_64-elf
Not one installs libada and I have gnattools:
$ ls ~/opt/tinyada/lib/gcc/arm-none-eabi/4.9.0/
include include-fixed install-tools plugin
$ ls ~/opt/tinyada/lib/gcc/mips-elf/4.9.0/
include include-fixed install-tools plugin
$ ls ~/opt/tinyada/lib/gcc/msp430-elf/4.9.0/
include include-fixed install-tools plugin
$ ls ~/opt/tinyada/lib/gcc/x86_64-elf/4.9.0/
include include-fixed install-tools plugin
Luke.
>From f8c74c16b9f7ef3be02a9a7d3480baf88d09efd6 Mon Sep 17 00:00:00 2001
From: "Luke A. Guest"
Date: Fri, 14 Feb 2014 13:53:27 +
Subject: [PATCH 1/2] Set the target for a bare metal environment.
---
gnattools/configure| 9 +
gnattools/configure.ac | 9 +
2 files changed, 18 insertions(+)
diff --git a/gnattools/configure b/gnattools/configure
index 883b705..b5bf03d 100755
--- a/gnattools/configure
+++ b/gnattools/configure
@@ -2090,6 +2090,15 @@ case "${target}" in
indepsw.adb>From a2b4516f93f4d99e5ddae4c1eed78f2014f0875b Mon Sep 17 00:00:00 2001
From: "Luke A. Guest"
Date: Fri, 14 Feb 2014 13:54:29 +
Subject: [PATCH 2/2] Added --enable-cross-gnattools flag for bare metal
environment.
---
configure| 25 ++--
configure.ac | 63
2 files changed, 61 insertions(+), 27 deletions(-)
diff --git a/configure b/configure
index 749a35e..c0d706d 100755
--- a/configure
+++ b/configure
@@ -749,6 +749,7 @@ enable_ld
enable_libquadmath
enable_libquadmath_support
enable_libada
+enable_cross_gnattools
enable_libssp
enable_libstdcxx
enable_static_libjava
@@ -1466,6 +1467,10 @@ Optional Features:
--disable-libquadmath-support
disable libquadmath support for Fortran
--enable-libada build libada directory
+ --enable-cross-gnattools
+ Enable cross gnattools for cross-compiler for
+ freestanding environment, --disable-libada is set
+ automatically
--enable-libssp build libssp directory
--disable-libstdcxx do not build libstdc++-v3 directory
--enable-static-libjava[=ARG]
@@ -3068,8 +3073,24 @@ else
ENABLE_LIBADA=yes
fi
-if test "${ENABLE_LIBADA}" != "yes" ; then
- noconfigdirs="$noconfigdirs gnattools"
+
+# Check whether --enable-cross-gnattools was given.
+if test "${enable_cross_gnattools+set}" = set; then :
+ enableval=$enable_cross_gnattools; ENABLE_CROSS_GNATTOOLS=$enableval
+else
+ ENABLE_CROSS_GNATTOOLS=yes
+fi
+
+
+if test "${is_cross_compiler}" = "yes" && test "${ENABLE_CROSS_GNATTOOLS}" = "yes" ; then
+ if test "${target_vendor}" = "none" || test "${target_vendor}" = "unknown" ; then
+enable_libada=no
+ENABLE_LIBADA=$enable_libada
+ fi
+else
+ if test "${ENABLE
Re: gnattools cannot be built for freestanding/bare metal environment without hacking up the build machinery
On Fri, 2014-02-14 at 15:32 +, Brian Drummond wrote: > OK I'll take a look. > Too many make and install targets; I have no idea how this process > interacts with the process specified here: > https://sourceforge.net/apps/mediawiki/mspgcc/index.php?title=Install:redhat > for the msp430, using (in short) Well, like I've said before that process won't work when you enable Ada, my patches will make it work, but you need to add the extra/new flag to configure. > make all-host > sudo make install-host > (Configure and build Newlib for MSP430) > make all-target > sudo make install-target > > Maybe that split build process actually resolves your issue... > But who can tell? : I can't say I've found adequate documentation. It really doesn't. > With the original (avr/msp430) patch/hack, gnattools were automatically > built and installed by make all-host, make install-host. Yes, but that hack is from avr-ada which, if you look back in this ml, I specifically state that it breaks normal builds. My patches, in theory, should not. Trust me, I've been trying to build these style tools for around 10 years, on and off, and they have never built correctly for these targets and any attempt to put in a bug report about it is a waste of time as someone comes along states it works and closes it, even though it doesn't. Luke.
Re: gnattools cannot be built for freestanding/bare metal environment without hacking up the build machinery
Hi, I've uploaded a prebuilt arm cross compiler for Linux x86_64, built on Debian Jessie, should work fine, crosses fingers :D https://www.dropbox.com/s/273e1pbez0qgqkp/tinyada-arm-none-eabi-4.9.0-20140122.tbz Thanks, Luke.
libada configure contains wrong code and GNAT as a cross compiler in general
Hi,
I'm trying to add GNAT to Yocto and still coming across problems. I have
a number of questions about GNAT as a cross compiler, I know it wasn't
designed as one within the GCC tree, but I think it needs to be capable
of building as one to match the other compilers.
1) The latest problem I'm having is that it fails to build
libgnat-4.6.so, I've managed to track it down to the following code
inside libada/configure:
# Determine what to build for 'gnatlib'
if test $build = $target \
&& test ${enable_shared} = yes ; then
# Note that build=target is almost certainly the wrong test; FIXME
default_gnatlib_target="gnatlib-shared"
else
default_gnatlib_target="gnatlib-plain"
fi
Surely, it shouldn't matter whether the $build = $target is true or not,
it should be whether the target supports shared libs or not. So, am I ok
to remove this test (keeping the enable_shared test)? Is there anything
else that could break because of this change?
In fact, should the code in libada/configure script actually do platform
tests, just as they are done in the gnattools/configure script?
2) I also want to point out that inside
gcc/ada/gcc-interface/Makefile.in there are lines such as:
GNATLIB_SHARED = gnatlib-shared-dual
Is these relics? If so, shouldn't the above configure script also use
the "-dual" and the other options available to it?
3) Coming back to gnattools, there are tests in there to set the
TOOLS_TARGET_PAIRS variable, which are also set in
gcc/ada/gcc-interface/Makefile.in, are the ones set in the Makefile.in
also relics? Can they be removed from there?
4) What is the point of the --disable-libada flag exactly? I've seen a
reference to there being a point, just not what that point is,
especially considering it disabled the build of gnattools and if you
disable the link between the two, the gnattools use the system runtime.
I don't understand this at all.
Thanks,
Luke.
Re: libada configure contains wrong code and GNAT as a cross compiler in general
On Wed, 2013-01-09 at 09:57 +0100, Arnaud Charlet wrote: > > 2) I also want to point out that inside > > gcc/ada/gcc-interface/Makefile.in there are lines such as: > > > > GNATLIB_SHARED = gnatlib-shared-dual > > > > Is these relics? > > No, these are correct settings. If there's a mistake, it might be in libada. These don't get picked up in libada and AFAICS there is no way for it to be passed from gcc/ada/gcc-interface/Makefile.in to libada, much like the next part below... > > If so, shouldn't the above configure script also use > > the "-dual" and the other options available to it? > > > > 3) Coming back to gnattools, there are tests in there to set the > > TOOLS_TARGET_PAIRS variable, which are also set in > > gcc/ada/gcc-interface/Makefile.in, are the ones set in the Makefile.in > > also relics? Can they be removed from there? > > No, these are not relics, these are actually the reference settings, When using --libada, these don't get used, you have to manually patch the configure in gnattools to get the correct working version of mlib, i.e. you won't get an mlib that supports library building on arm-none-eabi-gnulinux. > and used e.g. when using --disable-libada Ok, so they are used when that flag is in force? > > 4) What is the point of the --disable-libada flag exactly? I've seen a > > To disable automatic build of gnatlib and gnattools. This is used e.g. at > AdaCore to configure in a more fine grained manner how gnatlib and gnattools > are built. Ideally we'd like to use the libada/gnatools mechanism, but > this mechanism isn't quite working as we'd need it, so this hasn't happened > yet. How is this mechanism supposed to work? What is it really supposed to do? Is there a doc or spec somewhere that outlines what it was meant for? We need a bit more information if it is to be fixed. Thanks, Luke.
Re: libada configure contains wrong code and GNAT as a cross compiler in general
On Wed, 2013-01-09 at 08:43 +, Luke A. Guest wrote:
> 1) The latest problem I'm having is that it fails to build
> libgnat-4.6.so, I've managed to track it down to the following code
> inside libada/configure:
>
> # Determine what to build for 'gnatlib'
> if test $build = $target \
>&& test ${enable_shared} = yes ; then
> # Note that build=target is almost certainly the wrong test; FIXME
> default_gnatlib_target="gnatlib-shared"
> else
> default_gnatlib_target="gnatlib-plain"
> fi
>
> Surely, it shouldn't matter whether the $build = $target is true or not,
> it should be whether the target supports shared libs or not. So, am I ok
> to remove this test (keeping the enable_shared test)? Is there anything
> else that could break because of this change?
Ok, I will do a full build tonight with the testuite and take this "test
$build = $target" out of the build. I can only do a x86_64 linux test,
should I send the results to the list?
Luke.
Re: Restricted or no run time in Ada
Further to my last email, I managed to get it to work with no runtime, I've documented it as well, here: http://www.archeia.com/article-1199444859.html Luke.
What licence(s) does GNAT and the runtime fall under now?
Hi, I was just wondering what licences are used for GNAT now that AdaCore has GNAT-GPL rather than GNAT with GMGPL'd runtime. It seems that the source - when I last looked - for the runtime was GPL rather that GMGPL, but I thought that only the FSF could change the licence of these files? Can somebody please explain what licences are used for GCC-4.3.x & GNAT? Thanks, Luke.
Re: What licence(s) does GNAT and the runtime fall under now?
On Fri, 2008-03-21 at 14:20 -0400, Robert Dewar wrote: > Luke A. Guest wrote: > The license for the run-time sources at the FSF is the GMGPL. > > > > Can somebody please explain what licences are used for GCC-4.3.x & GNAT? Good to know, thanks. Luke.
Restricted or no run time in Ada
Hi, I got a simple hello world style multiboot kernel working again recently and it has got me thinking about how I should be using GNAT. Basically, I built a cross compiler for binutils and gcc to target i386-elf (I will be wanting to play with other targets in the future, e.g. mips-elf, arm-elf, sparc-elf, etc.). This gives me the following toolset: i386-elf-addr2line i386-elf-gcc i386-elf-gprof i386-elf-ranlib i386-elf-ari386-elf-gcc-4.2.2 i386-elf-ld i386-elf-readelf i386-elf-asi386-elf-gccbugi386-elf-nm i386-elf-size i386-elf-c++filt i386-elf-gcov i386-elf-objcopy i386-elf-strings i386-elf-cpp i386-elf-gnatbind i386-elf-objdump i386-elf-strip Which is fine enough as I can compile Ada sources with gcc. Now to get my kernel to compile I originally used pragma No_Run_Time which is now obsolete. I heard about the Zero Foot Print configurable runtime but couldn't get it to compile some of the source files and I couldn't figure out why. I then tried to use the new Ada 2005 pragma Restrictions and put the following in my gnat.adc: -- Basic stuff. pragma Restrictions(No_Obsolescent_Features); pragma Restrictions(No_Exceptions); pragma Restrictions(No_Recursion); -- Memory management. pragma Restrictions(No_Allocators); pragma Restrictions(No_Local_Allocators); pragma Restrictions(No_Unchecked_Deallocation); --pragma Restrictions(No_); -- Make sure we don't have tasking or any of it's features enabled. pragma Restrictions(Max_Tasks => 0); pragma Restrictions(No_Protected_Types); pragma Restrictions(No_Delay); pragma Restrictions(No_Task_Hierarchy); pragma Restrictions(No_Abort_Statements); pragma Restrictions(No_Implicit_Heap_Allocations); pragma Restrictions(No_Asynchronous_Control); I'm sure there are more I can use, I'm not sure about that. Now, AFAIK I'm fairly sure I don't need to use the binder as that will create a "main" including argc, argv, etc which you don't have in a kernel (obviously), but I'm sure there are some elaborations that aren't being done that I *should* have. I basically want to develop a microkernel that doesn't use the Ada runtime as an executive, I know this is the usual route, but I don't want to do that. An Ada runtime on top of my kernel is fine though. So, am I going the right way about this? Or is there something else I should be doing? Am I missing pragma's or using them wrong? Should I really be building a minimal runtime such that I can use Ada minus exceptions, tasking, etc? Thanks, Luke.
