Re: Documentation for .ldi file?

[Sergei Gavrikov <sergei dot gavrikov at gmail dot com>]

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