RFC: PowerPC bsp_specs Clean Up Question
chrisj at rtems.org
Thu Dec 21 22:51:40 UTC 2017
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
> > 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. :)
> > 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.
More information about the devel