RFC: PowerPC bsp_specs Clean Up Question

[Chris Johns]

On 22/12/2017 08:30, Joel Sherrill wrote:
> On Dec 21, 2017 3:03 PM, "Chris Johns" <chrisj at rtems.org
> <mailto:chrisj at rtems.org>> wrote:
>     On 22/12/2017 02:01, Joel Sherrill wrote:
>     > I'm not opposed to this but it requires even more delicate editing that I
>     can't
>     > easily test.
> 
>     If something breaks and it is reported we can look at fixing it. If something
>     breaks and it is not reported is it broken? ;)
> 
> Like a tree falling in the woods. :)
> 

Hehe

>     > We can get rid of bsp_specs and do this largely at the same time. The
>     > specifications in GCC will have to be tinkered with to address what's left in
>     > bsp_specs so the specs can do this.
> 
>     I think GCC's default configuration should be user focused and not BSP or
>     internally RTEMS focused. I see this meaning GCC's model is the same for all
>     BSPs and the options to access a BSP are similar.
> 
> 
> Agreed. I may be deeper in this mess and seeing things that aren't obvious at
> first glance. The crti/n, begin/end vary a bit per target architecture and (I
> think) the best we can do is go back to GCC default behavior as a baseline.
> Sebastian and you were hinting at that in an earlier message.
> 
> Switching between crt0.o and start.o is magic after that. 
> 
> FWIW I only see three linkcmds where STARTUP is not start.o. so that isn't hard
> to fix.
> 
> The entry symbol is usually a variant of start with 0 to 2 underscores. A
> handful have different symbols or appeared to start in the version.
> 

Post preinstall we can add a configure line the BSP configure.ac to the define
something specific if that helps.

> I can push what I have done and continue to nibble.
> 
> 
>     > But I haven't figured out precisely what to do with gcc at this point.
> 
>     The difficult part is locating start.o and similar object files. RTEMS currently
>     implements a horrible hack using -B. This option not only locates a bsp_specs
>     file it also adds a search path for locating .o and other files. I have only
>     just uncovered this as part of removing preinstall and it is a horrible problem
>     to solve. For example what happens if I create start.o in my application and
>     provide it on the command line to the linker with a -B to the location RTEMS's
>     start.o is located? Does GCC know what I want, is this option order dependent or
>     something else? A simple solution here is use RTEMS specific names but the idea
>     of needing -B seems wrong.
> 
> 
> -B is a standard option which specifies DIR is a system directory. Implies a -L
> and -I.
> 
> If it has magic beyond that, I don't see it.
> 

It is beyond -I and -L. The -L option only searches for libraries. The -B does
-I and -L and also finds .o files and I suspect linker scripts.

> Users providing their own start.o outside a BSP isn't a use case I want to worry
> about. If there is another reason to avoid -B, ok.

I am not saying the user provides a start.o to replace RTEMS's one, they just
happen to have a file called start.o as an application file.

> Also the -specs option is the one that bothers me the most. It implies reading a
> very GCC specific file.

The specs file has gone from all but the testsuite part of the source in my
no-preinstall work. It is only needed to link for a start symbol and may be the
start files. The critical option that is currently needed is -B to search for
the start.o because it is not defined by the build system which does know the
path rather it is "imported" from the default specs or a bsp_specs as just
'start.o'. I am OK with a -B inside the RTEMS build to create executables
however for the user I think we need a solution that does not reply on it.

Chris