From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6453 invoked by alias); 16 Sep 2013 22:00:04 -0000 Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Received: (qmail 6429 invoked by uid 89); 16 Sep 2013 22:00:03 -0000 Received: from mail-ea0-f181.google.com (HELO mail-ea0-f181.google.com) (209.85.215.181) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Mon, 16 Sep 2013 22:00:03 +0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_50,FREEMAIL_FROM,KHOP_THREADED autolearn=ham version=3.3.2 X-HELO: mail-ea0-f181.google.com Received: by mail-ea0-f181.google.com with SMTP id d10so2294637eaj.26 for ; Mon, 16 Sep 2013 14:59:59 -0700 (PDT) X-Received: by 10.15.94.201 with SMTP id bb49mr46486492eeb.23.1379368799404; Mon, 16 Sep 2013 14:59:59 -0700 (PDT) Received: from sg-laptop ([178.123.157.178]) by mx.google.com with ESMTPSA id z12sm45597972eev.6.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 16 Sep 2013 14:59:57 -0700 (PDT) Date: Mon, 16 Sep 2013 22:00:00 -0000 From: Sergei Gavrikov To: Grant Edwards cc: ecos-discuss@ecos.sourceware.org In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-IsSubscribed: yes Subject: Re: [ECOS] Documentation for .ldi file? X-SW-Source: 2013-09/txt/msg00006.txt.bz2 Hi Grant The below is far from your issue (customizing .ldi files for a CORTEX-M target), rather it is my attempt to enlighten new readers on, What those mlt/ldi files are? On Mon, 16 Sep 2013, Grant Edwards wrote: > Can somebody please point me to the documentation for writing a .ldi > file? ... [snip] Really, it is very conspiratorial thing :-) Even if we grep for (\) in the up-to-date eCos SGML files we find only 2 pages http://ecos.sourceware.org/docs-latest/user-guide/install-tree.html http://ecos.sourceware.org/docs-latest/user-guide/modifying-the-memory-layout.html MLT? http://ecos.sourceware.org/fom/ecos?_recurse=1&file=73#file_93 Fortunately, we can dig a bit more, if we take a look on user guides for previous eCos releases, for example we can find MLT's look and feel http://ecos.sourceware.org/docs-1.3.1/guides/user-guides.7.html IMO, eCos topics by the subject do lack a few important things 1) paltoform .ldi files (named "linker script fragments") write itself in C (they are CPP macros) and they will be processed then by CPP. Those C macros are defined in .ld file (see below). 2) any hal//arch/current/src/.ld file includes that "linker script fragment" as #include #include CYGHWR_MEMORY_LAYOUT_LDI 3) .ld (arm.ld, cortexm.ld, etc.) is not linker script, that is also C source, the source which will be post-processed then by CPP and we get $(PREFIX)/lib/target.ld script (real linker script for target). How it gets itself? You can GCC in CPP-mode (after `make headers' phase) to see result output -gcc -E -P -xc -I/include \ $(ECOS_REPOSITORY)/hal//arch/current/src/.ld For example # output `target.ld' for leon sparc-elf-gcc -E -P -xc -Iinstall/include \ $ECOS_REPOSITORY/hal/sparc/arch/current/src/sparc.ld Q: Can somebody please point me to the documentation for writing a .ldi file? A: You need to learn your .ld to known what those SECTION_* macros are and how to use them in the place then you will be able to get own memory layout in C. N.B.: But, look on the existing .ldi files first! > Why the multiple layers of obfuscation when just writing a gnu linker > script would be so much easier? As eCos ".ld files" are not linker scripts (they are written in C and they post-process itself with CPP) it is "easier" to customize a final linker script (target.ld). Not easier? :-) Thus, eCos ".ld files" let us to get complex target.ld using a few lines of macros (well, in most cases). More that, include #include lets us to use CDL values (substitute those values and get them in our `target.ld' script). And at the end eCos experts (hats off) gave us the complex .ld files as an excellent code base for usage! So, every memory layout file can re-use that code. Grant, what you mean, "much easier"? Much easier to write own GNU linker scripts for own platform? $EDITOR target.ld ;# IMO, $EDITOR mlt*ldi "easier" :-) > I get the impression that somehow all these layers were supposed to > allow people who know nothing about hardware, the Gnu toolchain or > embedded systems development do embedded systems development? Disagree. See above. Any .ld make you to know gory details. That "allow people who know nothing about hardware" was at the time of CT1+MLT http://ecos.sourceware.org/docs-1.3.1/guides/pix/memorywin.gif http://ecos.sourceware.org/docs-1.3.1/guides/pix/regprops.gif http://ecos.sourceware.org/docs-1.3.1/guides/pix/memregions.gif http://ecos.sourceware.org/docs-1.3.1/guides/pix/memreloc.gif IMO, that was not bad thing (I would s/know nothing/known a little/. So far, CT2 resist on using $EDITOR, it's not a bug, it's a feature :-) > AFAICT, it backfired and just makes it that much harder to create a > port and figure out what's wrong when something doesn't work. I am not arguing here that creating and testing non-trivial (not c&p) memory layout files is easy walk, but, I think that using syntax of GNU linker script in the place would not help much, at least, you may temporarily edit /lib/target.ld (bad advice?) and build/test executable before editing .ldi. By the way, cortexm.ld has USER_SECTION macro (arm.ld lacks) #define USER_SECTION(_name_, _region_, _vma_, _lma_) \ ._name_ _vma_ : _lma_ \ { __ ## _name_ ## _start = ABSOLUTE (.); \ *(._name_*) \ __ ## _name_ ## _end = ABSOLUTE (.); } \ > _region_ I must confess I have not used it. But, it seems this macro gives more freedom for .ldi designers. HTH Sergei -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss