Need Help to Further Reduce bsp_specs

Chris Johns chrisj at rtems.org
Wed Jan 10 22:18:33 UTC 2018


On 22/12/17 7:09 pm, Sebastian Huber wrote:
> On 21/12/17 08:15, Chris Johns wrote:
>> On 21/12/17 5:47 pm, Sebastian Huber wrote:
>>> Hello,
>>>
>>> we should try to understand better why the things are how they are currently.
>> Agreed.
>>
>>> In Newlib we have this ctr0.c:
>>>
>>> https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=blob;f=newlib/libc/sys/rtems/crt0.c;h=9778b985a180ba68990b40b6e4423aa970ca5ec7;hb=HEAD
>>>
>>>
>>>
>>> This is the default start file for the RTEMS GCC:
>>>
>>> https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/config/rtems.h?view=markup
>>>
>>>      /*
>>>       * Dummy start/end specification to let linker work as
>>>       * needed by autoconf scripts using this compiler.
>>>       */
>>>      #undef STARTFILE_SPEC
>>>      #define STARTFILE_SPEC "crt0.o%s"
>>>
>>> We use the bsp_specs to override this (we could also use -nostartfiles at the
>>> command line):
>>>
>>>              %rename startfile old_startfile
>>>
>>>              *startfile:
>>>              %{!qrtems: %(old_startfile)} \
>>>              %{!nostdlib: %{qrtems: crti.o%s crtbegin.o%s}}
>>>
>>> Why do we define a STARTFILE_SPEC in GCC which we don't use for real
>>> applications?
>>>
>> I good question. The gcc defaults should be focused on a user and the closer
>> this is to other platforms the better.
>>
>>> The purpose of the ctr0.o seems to be to make the Autoconf stuff happy during
>>> GCC build, e.g. for libstdc++.
>> Do other build system tests, ie autoconf, require an installed BSP?
> 
> If you do link-time checks then we support currently two variants.
> 
> 1. Via the Newlib ctr0.o which promises that a BSP will provide a proper
> implementation eventually (using other compiler/linker options).

Could you please provide a little more on detail on how this would work?

> 
> 2. You provide all options to link against the real BSP libraries.
> 

Is "you" a user?

> The support for 1. is actually quite nice. You can build libraries per multilib
> with it.

I think I see what you are asking but I am missing some of the detail to be certain.

> 
>>
>>> One option would be to do this:
>>>
>>> 1. Change STARTFILE_SPEC:
>>>
>>> #undef STARTFILE_SPEC
>>> #define STARTFILE_SPEC "start.o%s crti.o%s crtbegin.o"
>>>
>> What does a list mean?
> 
> Several startfiles. We also have endfiles.
> 
>>
>>> 2. Rename Newlib ctr0.o into start.o and do NOT install it. This way it is used
>>> only during GCC build to make the GCC Autoconf happy.
>> OK.
>>
>>> 3. Provide start.o in all BSPs.
>>>
>>> How do we deal with other Autoconf (or other link-time feature detection) stuff?
>>> This change could break all the third party library build scripts.
>> I do not think this can be avoided or we can never change what we have. I do not
>> like the use of -B on the gcc command line.
> 
> I think the -B switch is the only way to add search paths at the command line
> for startfiles, see "add_prefix.*startfile" in gcc/gcc.c.
> 

The -B option has side effects and I now feel after working on no-preinstall we
are better off without it. It's ability to search for .o, .a, linkcmds, and
bspspecs files makes it difficult to control. I have grown a dislike for it. Yes
it works however it is nerdy and complicated and we need to search for a way to
remove our dependence on it.

Chris


More information about the devel mailing list