rtems-libbsd: M68K linkcmds Patches Galore

[Sebastian Huber]

On 08/22/2012 01:39 AM, Kevin Polulak wrote:
> 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.

[...]

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

The compiler will generate no errors since its job is already done.  You get a 
linker error or a run-time error.  I don't know the m68k ABIs, but I doubt that 
this alignment is necessary.  Look at the default linker command file as a 
reference.

On ARM and PowerPC the linkcmds.base is derived from the corresponding default 
linker command file.

It is pretty easy to generate run-time errors due to changes in the linker 
command file, but they are easy to fix if you are able to run the BSP.  Since 
it is in most cases not possible to run a BSP on your own (e.g. due to a lack 
of boards and debuggers) its up to the BSP user to fix this.

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

A clean way would be to write a m68k version of a linkcmds.base using the 
default linker command file as a template.

>
> 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:

[...]

The m68k is an old architecture thus you see a history of debugging standards 
in the various linker command files.  The nature of copy and paste leads to 
this evolution.  The only relevant debugging definitions that are useful with 
the current tool chain are the ones from the default linker command file.

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

This is the way to do it.  Please rename this linkcmds.robsdsets to 
linkcmds.rortems.  Once we have this file we can start to put other stuff in 
it.  For example see

https://www.rtems.org/bugzilla/show_bug.cgi?id=1593

> /That's/ my dilemma and it's producing some build errors.

What for errors?  Do you have a log?

[...]

-- 
Sebastian Huber, embedded brains GmbH

Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany
Phone   : +49 89 18 90 80 79-6
Fax     : +49 89 18 90 80 79-9
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.