rtems-libbsd: M68K linkcmds Patches Galore

[Sebastian Huber]

On 08/20/2012 08:44 AM, Kevin Polulak wrote:
> On 8/17/2012 4:13 AM, Sebastian Huber wrote:
>> I don't like this format.  Each time you change the length of one field in
>> the columns you have to adjust other lines as well.  This makes a review harder.
>
> So code should remain cryptic and hard to follow because git-diff formats
> things strange sometimes? A review of the .diff output may be hard but a review
> of the actual code is even harder. That's Git's fault. I was just trying to
> clean things up for the next poor guy who has to look at it.
>
> Say "hello" to my logic:
>
> I perform task A and I like to do task B and I do task C.
> I do the same thing as A and I do something like B and I'm identical to C.
>
> Versus:
>
> I perform task A          and I like to do task B    and I sometimes do task C.
> I do the same thing as A  and I do something like B  and I'm identical to C.
>
> The tabular flow forms these invisible columns that 1) are easier on the eyes
> and 2) group similar things together.
>
> +-----------------------------------------------------------------------------------+
> |          TASK A          |           TASK B |           TASK C           |
> +-----------------------------------------------------------------------------------+
> | I perform task A         | and I like to do task B   | and I sometimes do
> task C. |
> | I do the same thing as A | and I do something like B | and I'm identical to
> C.    |
> +-----------------------------------------------------------------------------------+
>
> (Hoping my email client doesn't screw up that formatting for me.)

Sorry, I didn't want to start a style discussion.  You can do it that way, but 
I don't like it since this will lead to repetitive white space changes.

>
>> If you look at the default linker command file (e.g. m68k-rtems4.11-ld
>> --verbose) then you will see that the previous format is used here (space
>> before "(").
>
> That's fine. I always say: I could care less what the format is, just so long
> as it's followed. Sometimes there was a space, sometimes there wasn't and it
> just seemed like there were more "no spaces" so that's what I went with. Easy
> change.

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

>
>> Why is this linkcmds.robsdsets and not linkcmds.rortems?
>
> Didn't even realize I did that. The name got stuck in my head from typing it so
> many times and I guess it stuck.
>
>> Why do we have CPU specific variants of this?  On ARM, PowerPC, etc. this
>> file would look like identical.
>
> You mean because it's in m68k/shared? I didn't know where else to put
> linkcmds.rortems. Joel said to use your's or Gedare's way (I have no clue,
> everyone's e-face blends together for me) from ARM so that's what I did.
> There's still about 95% of unexplored RTEMS territory for me so I didn't want
> to waste time trying to do something I didn't know how to. How do I make it
> "attention all BSP's, you use this linkcmds file and you use it now!"? ;)

I would name the files "cpukit/score/lib/linkcmds.rortems" and 
"cpukit/score/lib/linkcmds.rwrtems".

>
> And skipping forward to all this other GCC __underscore__ talk...
>
> Hold on. Timeout.
>
> To be honest, I don't even have a clue what that stuff is inside
> linkcmds.robsdsets. I did a git-grep on some of those symbols a while back and
> didn't find them referenced anywhere so their purpose has always eluded me. But
> they fix the linkage issues so that's just what I put in there.

See

http://git.rtems.org/rtems-libbsd.git/tree/freebsd/sys/linker_set.h

>
> But I'm not sure how the conversation got on this though? I mean, whatever that
> stuff is, it works. What I was struggling with is including it in an external
> file (i.e. linkcmds.rortems). So somehow that train of thought didn't make a
> stop at my boarding station and I'm kinda still waiting to be picked up. :/
>
> (By the way, this
> <http://sourceware.org/binutils/docs-2.17/ld/Source-Code-Reference.html#Source-Code-Reference>
> says it's a compiler "feature".)

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

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