From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.182.246.195 with SMTP id xy3mr8721855obc.45.1413155902226; Sun, 12 Oct 2014 16:18:22 -0700 (PDT) X-Received: by 10.140.97.10 with SMTP id l10mr322813qge.1.1413155902192; Sun, 12 Oct 2014 16:18:22 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!news.glorb.com!uq10no9520863igb.0!news-out.google.com!i10ni83qaf.0!nntp.google.com!s7no2300571qap.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Sun, 12 Oct 2014 16:18:22 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=90.216.80.117; posting-account=L2-UcQkAAAAfd_BqbeNHs3XeM0jTXloS NNTP-Posting-Host: 90.216.80.117 References: <87h9zdpi84.fsf@ixod.org> <87fvex5bwy.fsf@ixod.org> <2064812074434669488.767131laguest-archeia.com@nntp.aioe.org> <1196941186434813066.828500laguest-archeia.com@nntp.aioe.org> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <0ec29b17-286e-49c3-a26c-88e5161ebda4@googlegroups.com> Subject: Re: Cross-toolchain for DS [was: Newcomers to comp.lang.ada: welcome and how did you end up here ?] From: Lucretia Injection-Date: Sun, 12 Oct 2014 23:18:22 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Xref: news.eternal-september.org comp.lang.ada:22406 Date: 2014-10-12T16:18:22-07:00 List-Id: On Sunday, 12 October 2014 14:52:04 UTC+1, Natasha Kerensikova wrote: > Hello, >=20 > On 2014-10-12, Luke A Guest wrote: >=20 > > I wouldn't use that patch. When I get home I'll explain it and why you > > don't want to use it and I'll show you a better way. >=20 > I'm looking forward to it. Right, this is all from memory and I'll be referencing this https://github.= com/Lucretia/tamp/blob/master/thirdparty/patches/gcc-4.6.1/gcc-4.6.1.diff f= ile. In the adaint.c file, I'm essentially making various functions available to= the runtime for targets where __arm__ and __ELF__ preprocessor symbols are= defined. This is so the runtime will link properly. I'm also returning def= ault valus where they don't exist. In gcc-interface/Makefile.in I add a ifdef block to check if the target we = want is arm-eabi-elf and if so, define what runtime packages are used in bu= ilding the tools, including the all important system.ads. In this block I m= ention that TOOLS_TARGET_PAIRS is mentioned within that file, but not used.= This is a lack of cleanup from the gcc guys when they moved the building o= f the runtime to gcc-x.x.x/gnattools directory - and yeah, it's really conf= using that it's still there. Provided an entire mlib-tgt-specific-bare.adb which isn't required anymore = as there is a specific version for bare metal runtimes now included in FSF = GCC sources. This is the mlib-tgt-specific-xi.adb file. Need to add system-bare-armel.ads, which is just an edit of one of the othe= r system-*.ads files. As mentioned above, gnattools/configure, is where the TOOLS_TARGET_PAIRS ar= e now defined, so I added a case selection for arm-eabi-elf, this then tell= s teh configure script which mlib-tgt-specific-* file to use to build the g= nat tools. This file defines whether you have dynamic linking for example, = for bare metal compilers, static is all you get and this is what the *xi* s= pecific package provides. Repeated for the .ac files. The above provides a way to build that specific target without messing too = much with the build infrastructure. This also builds a runtime, which is co= mpletely pointless and will never be used. This is not the way Rolf does it= for AVR and subsequently Brian Drummond for MSP430, see the thread here ht= tps://gcc.gnu.org/ml/gcc/2014-01/msg00139.html and this is because they bre= ak the build by removing the dependency of libada on gnattools from the mai= n configure script. The idea really is to be able to turn off the build of the runtime when the= target is something like *-elf or *-coff where there is no OS and therefor= e no libc. My last version (and this almost works cleanly) is referenced fr= om here https://gcc.gnu.org/ml/gcc/2014-02/msg00205.html (finally found it!= ) In that set of patches, I added the gnattools/configure patch like before b= ut generalised for targets that are matched by "*-*-elf* | *-*-eabi*" and p= oint to the mlib-tgt-specific-xi.adb. Added a new flag to the main configure script --enable-cross-gnattools whic= h essentially does what the AVR/MSP hack does, but in a non-destructive way= , in other words, you can still build a normal hosted compiler with this pa= tched source (never tested) as well a cross compiler with no rts but with g= nattools. That's all there was to those patches. Easy. You just need to supply your o= wn RTS which you compile yourself, see tamp for a gpr based one. Also, see = the above link on that last patch as I explain that for some reason you can= not build cleanly, for some reason the build stops, you have to clear a sta= mp file then restart, it's fiddly, but I'd like to get it to a point where = it works cleanly and can be submitted back to FSF for inclusion. If anyone = knows configure scripts better than me, can you apply it and check it to se= e what I've missing? Thanks. Luke A. Guest.