<div dir="auto"><div><br><div class="gmail_extra"><br><div class="gmail_quote">On Dec 21, 2017 3:03 PM, "Chris Johns" <<a href="mailto:chrisj@rtems.org">chrisj@rtems.org</a>> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="quoted-text">On 22/12/2017 02:01, Joel Sherrill wrote:<br>
> I'm not opposed to this but it requires even more delicate editing that I can't<br>
> easily test.<br>
<br>
</div>If something breaks and it is reported we can look at fixing it. If something<br>
breaks and it is not reported is it broken? ;)<br></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">Like a tree falling in the woods. :)</div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="quoted-text"><br>
> We can get rid of bsp_specs and do this largely at the same time. The<br>
> specifications in GCC will have to be tinkered with to address what's left in<br>
> bsp_specs so the specs can do this.<br>
<br>
</div>I think GCC's default configuration should be user focused and not BSP or<br>
internally RTEMS focused. I see this meaning GCC's model is the same for all<br>
BSPs and the options to access a BSP are similar.<br></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">Switching between crt0.o and start.o is magic after that. </div><div dir="auto"><br></div><div dir="auto">FWIW I only see three linkcmds where STARTUP is not start.o. so that isn't hard to fix.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">I can push what I have done and continue to nibble.</div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="quoted-text"><br>
> But I haven't figured out precisely what to do with gcc at this point.<br>
<br>
</div>The difficult part is locating start.o and similar object files. RTEMS currently<br>
implements a horrible hack using -B. This option not only locates a bsp_specs<br>
file it also adds a search path for locating .o and other files. I have only<br>
just uncovered this as part of removing preinstall and it is a horrible problem<br>
to solve. For example what happens if I create start.o in my application and<br>
provide it on the command line to the linker with a -B to the location RTEMS's<br>
start.o is located? Does GCC know what I want, is this option order dependent or<br>
something else? A simple solution here is use RTEMS specific names but the idea<br>
of needing -B seems wrong.<br></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">-B is a standard option which specifies DIR is a system directory. Implies a -L and -I.</div><div dir="auto"><br></div><div dir="auto">If it has magic beyond that, I don't see it.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">Also the -specs option is the one that bothers me the most. It implies reading a very GCC specific file.</div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<font color="#888888"><br>
Chris<br>
</font></blockquote></div><br></div></div></div>