I would like to use tasking support for GNAT on an arm-linux target (Intel XSCale PXA 270) to the gcc-4_1-branch The installed runtime library however is using generic dummy package for tasking support (e.g. s-taprop.ads). After having a look at gcc/ada/Makefile.in, I figured there needs to be a couple of changes: 1. need for system-linux-arm.ads - which can be identical to system-linux-x86.ads 2. The Makefile.in needs to be changed as follows: (g-soccon is not in my focus, so I just kicked it out for now) (a-numaux is using the libc bindings) (all the rest of this section is from the x86-linux part) Index: Makefile.in =================================================================== --- Makefile.in (revision 117213) +++ Makefile.in (working copy) @@ -539,6 +539,33 @@ EXTRA_GNATRTL_TASKING_OBJS=s-vxwork.o endif +ifeq ($(strip $(filter-out arm linux%,$(arch) $(osys))),) + LIBGNAT_TARGET_PAIRS = \ + a-intnam.ads<a-intnam-linux.ads \ + a-numaux.ads<a-numaux-libc-x86.ads \ + s-inmaop.adb<s-inmaop-posix.adb \ + s-intman.adb<s-intman-posix.adb \ + s-osinte.adb<s-osinte-posix.adb \ + s-osinte.ads<s-osinte-linux.ads \ + s-osprim.adb<s-osprim-posix.adb \ + s-taprop.adb<s-taprop-linux.adb \ + s-taspri.ads<s-taspri-posix.ads \ + s-tpopsp.adb<s-tpopsp-posix-foreign.adb \ + s-parame.adb<s-parame-linux.adb \ + system.ads<system-linux-arm.ads + + TOOLS_TARGET_PAIRS = \ + mlib-tgt.adb<mlib-tgt-linux.adb \ + indepsw.adb<indepsw-gnu.adb + + EH_MECHANISM=-gcc + THREADSLIB = -lpthread + GNATLIB_SHARED = gnatlib-shared-dual + GMEM_LIB = gmemlib + PREFIX_OBJS = $(PREFIX_REAL_OBJS) + LIBRARY_VERSION := $(LIB_VERSION) +endif + ifeq ($(strip $(filter-out arm% coff wrs vx%,$(targ))),) LIBGNAT_TARGET_PAIRS = \ a-intnam.ads<a-intnam-vxworks.ads \ Did I forget anything? Unfortunately, I don't have a running (native) compiler (yet??), so ACATS tests might be hard to do.
(In reply to comment #0) actually, the Makefile.in needs modifications. a-numaux-x86.ads does not work for arm (error-message is that only 15 digits are allowed for floating point type), therefore the line + a-numaux.ads<a-numaux-libc-x86.ads \ should be removed in the section. Compiler is build fine (build=i686-pc-linux-gnu, host=i686-pc-linux-gnu) and the files get installed in adainclude/adalib as expected. I even was able to compile a simple tasking program.
Created attachment 12346 [details] hello world source code
Created attachment 12347 [details] simple_tasking source code
...running the above programs give me the following errors/messages: root@colibri:/testprogs/glibc# ./simple_tasking Alignment trap: simple_tasking (1099) PC=0x0000a670 Instr=0xe5933000 Address=0x00000001 FSR 0x0f3 raised STORAGE_ERROR : s-intman.adb:158 explicit raise root@colibri:/testprogs/glibc# root@colibri:/testprogs/glibc# root@colibri:/testprogs/glibc# ls hello hello_threaded hello_world simple_tasking root@colibri:/testprogs/glibc# ./hello_world Hello World so it seems, there's something fishy for the tasking setup - any good idea to trace this up? (I don't have a debugger at hand *grrr*)
Hi, s-osinte.ads<s-osinte-linux.ads This might need a bit more work, some structure size and such might not be identical between versions. You should look at the s-osinte-linux-alpha.ads and s-osinte-linux-hppa.ads diffs with s-osinte-linux.ads to get an idea of what kind of changes could be needed. Hope this helps.
(In reply to comment #5) > Hi, > > s-osinte.ads<s-osinte-linux.ads > > This might need a bit more work, some structure size and such might not be > identical between versions. You should look at the s-osinte-linux-alpha.ads and > s-osinte-linux-hppa.ads diffs with s-osinte-linux.ads to get an idea of what > kind of changes could be needed. > > Hope this helps. > ... well, I can see differences, but is there any definite way of finding out, how the C structures actually look like? Do I have to hunt this up in the glibc source code? (the signal values should be easily obtainable with a little C program - but the other stuff?)
Subject: Re: Adding tasking support for arm-linux > ... well, I can see differences, but is there any definite way of finding out, > how the C structures actually look like? Do I have to hunt this up in the > glibc source code? You need to retrieve the values and struct definitions from the include files present on your system. Arno
Unless the submitter intends to work on this PR, I doubt anything will happen, so closing for now. If someone is interested in working on this, feel free to reopen and assign to you. Arno