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 (\<mlt|ldi\>) 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 <arch>.ld file (see below). 2) any hal/<arch>/arch/current/src/<arch>.ld file includes that "linker script fragment" as #include <pkgconf/system.h> #include CYGHWR_MEMORY_LAYOUT_LDI 3) <arch>.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 <TARGET>-gcc -E -P -xc -I<PREFIX>/include \ $(ECOS_REPOSITORY)/hal/<arch>/arch/current/src/<arch>.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 <arch>.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 <pkgconf/system.h> 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 <arch>.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 <arch>.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 <PREFIX>/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
