rtems-libbsd: M68K linkcmds Patches Galore

Sebastian Huber sebastian.huber at embedded-brains.de
Mon Aug 20 07:28:28 UTC 2012

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


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

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



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

More information about the devel mailing list