rtems-libbsd: M68K linkcmds Patches Galore

[Ralf Corsepius]

On 08/17/2012 04:34 PM, Joel Sherrill wrote:
> On 08/17/2012 08:46 AM, Ralf Corsepius wrote:
>> On 08/17/2012 03:23 PM, Sebastian Huber wrote:
>>> On 08/17/2012 03:02 PM, Joel Sherrill wrote:
>>>>> Why do we have CPU specific variants of this?  On ARM, PowerPC, etc.
>>>>> this file
>>>>> would look like identical.
>>>> Some targets place a leading underscore in front of symbols. If you
>>>> have every
>>>> symbol both with and without an extra _ prepended, then it will be Ok.
>>>> For
>>>> example,
>>>> both _bsd__stop_set_sysinit_set and __bsd__stop_set_sysinit_set would
>>>> have
>>>> to be defined.
>>>>
>>>> This is all the targets I have tools installed for and whether or not
>>>> they add a
>>>> leading underscore.
>>>>
>>>>          arm-rtems4.11 - no leading underscore
>>>>          avr-rtems4.11 - no leading underscore
>>>>         bfin-rtems4.11 - leading underscore
>>>>        h8300-rtems4.11 - leading underscore
>>>>         i386-rtems4.11 - no leading underscore
>>>>         lm32-rtems4.11 - no leading underscore
>>>>         m32c-rtems4.11 - leading underscore
>>>>         m32r-rtems4.11 - no leading underscore
>>>>         m68k-rtems4.11 - no leading underscore
>>>> microblaze-rtems4.11 - no leading underscore
>>>>         mips-rtems4.11 - no leading underscore
>>>>      powerpc-rtems4.11 - no leading underscore
>>>>           sh-rtems4.11 - leading underscore
>>>>      sparc64-rtems4.11 - no leading underscore
>>>>        sparc-rtems4.11 - no leading underscore
>>>>         v850-rtems4.11 - leading underscore
>>> With this extra underscore can be dealt in the macros that generate
>>> these symbols.
>>>
>>> The CPU port should provide a macro like
>>>
>>> #define CPU_LINKER_SYMBOL_NAME(_x) _ ## _x
>>>
>>> or
>>>
>>> #define CPU_LINKER_SYMBOL_NAME(_x) _x
>> It's already there: cf. cpukit/score/cpu/<cpu>/*.h
> So he can check that as well. The truth is what gcc actually does.
Unfortunately no, rsp. to be checked. Ca. 10 years+ ago, when these GCC 
derived "_" were added to RTEMS (before, they had been hard-coded), 
there were cases, GCC emitted not all of them correctly, and we had to 
resort to manually overriding them.

> I produced that list by checking whether printf() in libc was printf
> or _printf.
Well, the easiest way to handle this issue would be to apply autoconf.

However as a consequence of the recent demonstration of some key RTEMS 
users lacking sufficient understanding on the autotools, I will leave 
implementing this as an educational exercise to these people.

>> Also GCC internally provides some preprocessor defines to help detecting
>> them. Unfortunately, for historic reasons, there are cases these defines
>> are broken.
>>
>>> Even if we deal with the underscore in the linker command files, then I
>>> see only two variants and not one for each CPU.
>> Openly said, I am not sure this currently ongoing effort will be a
>> success. Several similar attempts in RTEMS history repeatedly had 
>> failed.
> Sebastian has successfully converted a number of BSPs over to
> shared linker scripts. It is a difficult task but that doesn't make it
> impossible.
Sebastian only works with his BSPs and EMB's BSPs, which all share a 
very similar design and origin and only cover some architectures.

 From 10years+ ago,I recall the m68k and the powerpc BSPs having being 
extraordinarily difficult (Due to their different origins) and the 
sh-BSPs having had issues related to using non-consecutive memory.

Ralf