rtems-libbsd: M68K linkcmds Patches Galore

[Kevin Polulak]

On 8/20/2012 3:28 AM, Sebastian Huber wrote:
> If you need a linker command file template, then please use the 
> default linker command file or
>
> http://git.rtems.org/rtems/tree/c/src/lib/libbsp/arm/shared/startup/linkcmds.base 
>

See below. Like I said, a template isn't possible.

> What do you mean with "including it in an external file".

Using INCLUDE linkcmds.robsdsets. The thing I kinda started this thread 
about. It's still not working.

I saw your discussion on GCC's Bugzilla tracker about adding 
REGION_ALIAS (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 .text, same .eh_frame, same .rodata etc. and all in the same exact 
order. The only difference is what region of memory they're placed in. 
Hence, the use of REGION_ALIAS.

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 .data section looks like this:

.data :
{
     PROVIDE (_data_dest_start = .);
     PROVIDE (_copy_start = .);

     *(.data*)
     *(.gnu.linkonce.d*)
     *(.gcc_except_table*)
     *(.jcr)

     . = ALIGN (16);
     PROVIDE (_edata = .);
     PROVIDE (_copy_end = .);
     PROVIDE (_data_dest_end = .);
} > ram

Compared to the .data section for csb360:

.data :
{
     copy_start = .;
     *(.shdata)

     . = ALIGN (0x10);
     *(.data*)

     . = ALIGN (0x10);
     *(.gcc_exc)
     *(.gcc_except_table*)
     *(.jcr)

     . = ALIGN (0x10);
     *(.gnu.linkonce.d*)

     . = ALIGN (0x10);
     _edata   = .;
     copy_end = .;
} > ram

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.

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 INCLUDE.

For example, most of the BSP's have some sort of debug section. Keyword 
being /most/; not /all/. 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:

.stab          0 : { *(.stab)          }
.stabstr       0 : { *(.stabstr)       }
.stab.excl     0 : { *(.stab.excl)     }
.stab.exclstr  0 : { *(stab.exclstr)   }
.stab.index    0 : { *(.stab.index)    }
.stab.indexstr 0 : { *(.stab.indexstr) }
.comment       0 : { *(.comment)       }

Then this in linkcmds.dwarf:

.debug          0 : { *(.debug) }
.line           0 : { *(.line) }

.debug_srcinfo  0 : { *(.debug_srcinfo) }
.debug_sfnames  0 : { *(.debug_sfnames) }

.debug_aranges  0 : { *(.debug_aranges)  }
.debug_pubnames 0 : { *(.debug_pubnames) }

.debug_info     0 : { *(.debug_info)    }
.debug_abbrev   0 : { *(.debug_abbrev)  }
.debug_line     0 : { *(.debug_line)    }
.debug_frame    0 : { *(.debug_frame)   }
.debug_str      0 : { *(.debug_str)     }
.debug_loc      0 : { *(.debug_loc)     }
.debug_macinfo  0 : { *(.debug_macinfo) }

.debug_weaknames 0 : { *(.debug_weaknames) }
.debug_funcnames 0 : { *(.debug_funcnames) }
.debug_typenames 0 : { *(.debug_typenames) }
.debug_varnames  0 : { *(.debug_varnames)  }

And this in linkcmds.debug:

INCLUDE linkcmds.stabs
INCLUDE linkcmds.dwarf

Then when a board like av5282 needs the stabs stuff at the end, simply 
replace it with INCLUDE linkcmds.stabs. If a board needs only the DWARF 
stuff, replace it with INCLUDE linkcmds.dwarf. If a board like gen68340 
needs both, then INCLUDE linkcmds.debug. All the common stuff is neatly 
written once and included where necessary.

That's what I've been trying to do with .robsdsets. 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 
.robsdsets.

Since the symbols are always the same (not sure about other 
architectures, but at least for M68K), I can pull them out into /an 
external file/ 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 .robsdsets sits within memory. 
Therefore, instead of having an inline .robsdsets for each BSP, I can do:

.robsdsets :
{
     INCLUDE linkcmds.robsdsets
} > whatever_region_this_bsp_wants

/That's/ 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 INCLUDE business gets sorted out.

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.

-- 
- Kevin Polulak (soh_cah_toa)
- http://cybercrud.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20120821/003be10e/attachment-0001.html>