<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 8/20/2012 3:28 AM, Sebastian Huber
      wrote:<br>
    </div>
    <blockquote cite="mid:5031E71C.1030202@embedded-brains.de"
      type="cite">If you need a linker command file template, then
      please use the default linker command file or
      <br>
      <br>
<a class="moz-txt-link-freetext" href="http://git.rtems.org/rtems/tree/c/src/lib/libbsp/arm/shared/startup/linkcmds.base">http://git.rtems.org/rtems/tree/c/src/lib/libbsp/arm/shared/startup/linkcmds.base</a>
      <br>
    </blockquote>
    <br>
    See below. Like I said, a template isn't possible.<br>
    <br>
    <blockquote cite="mid:5031E71C.1030202@embedded-brains.de"
      type="cite">What do you mean with "including it in an external
      file".
      <br>
    </blockquote>
    <br>
    Using <tt>INCLUDE linkcmds.robsdsets</tt>. The thing I kinda
    started this thread about. It's still not working.<br>
    <br>
    I saw your discussion on GCC's Bugzilla tracker about adding <tt>REGION_ALIAS</tt>
    (nice job, by the way) and how you made linkcmds.base into a
    template file. What I was saying is that it's just not possible for
    M68K. For ARM, the memory layout is the exactly the same for each
    BSP; same <tt>.text</tt>, same <tt>.eh_frame</tt>, same <tt>.rodata</tt>
    etc. and all in the same exact order. The only difference is what
    region of memory they're placed in. Hence, the use of <tt>REGION_ALIAS</tt>.<br>
    <br>
    However, that's not the case for M68K. There are usually anywhere
    from subtle to significant differences between the segments for each
    BSP. For instance, the av5282's <tt>.data</tt> section looks like
    this:<br>
    <br>
    <tt>.data :<br>
      {<br>
          PROVIDE (_data_dest_start = .);<br>
          PROVIDE (_copy_start = .);<br>
      <br>
          *(.data*)<br>
          *(.gnu.linkonce.d*)<br>
          *(.gcc_except_table*)<br>
          *(.jcr)<br>
      <br>
          . = ALIGN (16);<br>
          PROVIDE (_edata = .);<br>
          PROVIDE (_copy_end = .);<br>
          PROVIDE (_data_dest_end = .);<br>
      } > ram</tt><br>
    <br>
    Compared to the <tt>.data</tt> section for csb360:<br>
    <br>
    <tt>.data :<br>
      {<br>
          copy_start = .;<br>
          *(.shdata)<br>
      <br>
          . = ALIGN (0x10);<br>
          *(.data*)<br>
      <br>
          . = ALIGN (0x10);<br>
          *(.gcc_exc)<br>
          *(.gcc_except_table*)<br>
          *(.jcr)<br>
      <br>
          . = ALIGN (0x10);<br>
          *(.gnu.linkonce.d*)<br>
      <br>
          . = ALIGN (0x10);<br>
          _edata   = .;<br>
          copy_end = .;<br>
      } > ram</tt><br>
    <br>
    As you can see, they're kinda similar but clearly, csb360 is more
    strict about 16-byte alignment and I'm not sure how other BSP's
    would react to that if I put that in a template file. My guess is
    that I'd probably be greeted by an angry mob of compiler errors
    bearing pitchforks and torches. It's simply impossible to make a
    common template file since none of it is the same.<br>
    <br>
    But, like I said, some redundancies can still be reduced by simply
    pulling out some of the pieces that are exactly the same across
    boards (it's obvious some of them have literally been copy and
    pasted; they're the sloppy parts) and replacing them with <tt>INCLUDE</tt>.<br>
    <br>
    For example, most of the BSP's have some sort of debug section.
    Keyword being <i>most</i>; not <i>all</i>. Some have sections for
    stabs, some for DWARF, and some have both. All I'd need to do is
    stick this in something like linkcmds.stabs:<br>
    <br>
    <tt>.stab          0 : { *(.stab)          }<br>
      .stabstr       0 : { *(.stabstr)       }<br>
      .stab.excl     0 : { *(.stab.excl)     }<br>
      .stab.exclstr  0 : { *(stab.exclstr)   }<br>
      .stab.index    0 : { *(.stab.index)    }<br>
      .stab.indexstr 0 : { *(.stab.indexstr) }<br>
      .comment       0 : { *(.comment)       }</tt><br>
    <br>
    Then this in linkcmds.dwarf:<br>
    <tt><br>
      .debug          0 : { *(.debug) }<br>
      .line           0 : { *(.line) }<br>
      <br>
      .debug_srcinfo  0 : { *(.debug_srcinfo) }<br>
      .debug_sfnames  0 : { *(.debug_sfnames) }<br>
      <br>
      .debug_aranges  0 : { *(.debug_aranges)  }<br>
      .debug_pubnames 0 : { *(.debug_pubnames) }<br>
      <br>
      .debug_info     0 : { *(.debug_info)    }<br>
      .debug_abbrev   0 : { *(.debug_abbrev)  }<br>
      .debug_line     0 : { *(.debug_line)    }<br>
      .debug_frame    0 : { *(.debug_frame)   }<br>
      .debug_str      0 : { *(.debug_str)     }<br>
      .debug_loc      0 : { *(.debug_loc)     }<br>
      .debug_macinfo  0 : { *(.debug_macinfo) }<br>
      <br>
      .debug_weaknames 0 : { *(.debug_weaknames) }<br>
      .debug_funcnames 0 : { *(.debug_funcnames) }<br>
      .debug_typenames 0 : { *(.debug_typenames) }<br>
      .debug_varnames  0 : { *(.debug_varnames)  }</tt><br>
    <br>
    And this in linkcmds.debug:<br>
    <br>
    <tt>INCLUDE linkcmds.stabs<br>
      INCLUDE linkcmds.dwarf</tt><br>
    <br>
    Then when a board like av5282 needs the stabs stuff at the end,
    simply replace it with <tt>INCLUDE linkcmds.stabs</tt>. If a board
    needs only the DWARF stuff, replace it with <tt>INCLUDE
      linkcmds.dwarf</tt>. If a board like gen68340 needs both, then <tt>INCLUDE
      linkcmds.debug</tt>. All the common stuff is neatly written once
    and included where necessary.<br>
    <br>
    That's what I've been trying to do with <tt>.robsdsets</tt>. All
    those BSP's are guaranteed to need one and they're gonna be the same
    thing, every time. Now I know I've explained this like three times
    in other discussions but I'll give it another shot. It's the same
    thing I just described but with <tt>.robsdsets</tt>.<br>
    <br>
    Since the symbols are always the same (not sure about other
    architectures, but at least for M68K), I can pull them out into <i>an
      external file</i> like linkcmds.robsdsets. Now I remember why
    that's the name since that's the only thing I can put in there. The
    only thing different between BSP's is where <tt>.robsdsets</tt>
    sits within memory. Therefore, instead of having an inline <tt>.robsdsets</tt>
    for each BSP, I can do:<br>
    <br>
    <tt>.robsdsets : <br>
      {<br>
          INCLUDE linkcmds.robsdsets<br>
      } > whatever_region_this_bsp_wants</tt><br>
    <br>
    <i>That's</i> my dilemma and it's producing some build errors. I
    attached a patch a while back of what this would look like for some
    BSP but I forget which one. I have all these inline patches ready to
    go but I've been holding off until all this <tt>INCLUDE</tt>
    business gets sorted out.<br>
    <br>
    I'm certainly no RTEMS expert so it's likely that I could be totally
    wrong and perhaps there may be some other way of accomplishing this.
    Personally, I wish your way was possible here since it plays nicely
    with my CCC philosophy: clean, consistent, code. But from what I've
    gathered, I just don't see any other way.<br>
    <br>
    <div class="moz-signature">-- <br>
      - Kevin Polulak (soh_cah_toa)<br>
      - <a class="moz-txt-link-freetext" href="http://cybercrud.net">http://cybercrud.net</a></div>
  </body>
</html>