rtems-libbsd: M68K linkcmds Patches Galore
ralf.corsepius at rtems.org
Fri Aug 17 14:57:37 UTC 2012
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.
>>>> both _bsd__stop_set_sysinit_set and __bsd__stop_set_sysinit_set would
>>>> 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
>>> #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
> Sebastian has successfully converted a number of BSPs over to
> shared linker scripts. It is a difficult task but that doesn't make it
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.
More information about the devel