<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 5, 2016 at 12:54 PM, Gedare Bloom <span dir="ltr"><<a href="mailto:gedare@rtems.org" target="_blank">gedare@rtems.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Tue, Jan 5, 2016 at 1:10 PM, Joel Sherrill <<a href="mailto:joel@rtems.org">joel@rtems.org</a>> wrote:<br>
><br>
> On Jan 5, 2016 4:35 AM, "Sebastian Huber"<br>
> <<a href="mailto:sebastian.huber@embedded-brains.de">sebastian.huber@embedded-brains.de</a>> wrote:<br>
>><br>
>><br>
>><br>
>> On 04/01/16 03:47, Joel Sherrill wrote:<br>
>><br>
>>><br>
>>><br>
>>> On Sun, Jan 3, 2016 at 8:26 PM, Chris Johns <<a href="mailto:chrisj@rtems.org">chrisj@rtems.org</a><br>
>>> <mailto:<a href="mailto:chrisj@rtems.org">chrisj@rtems.org</a>>> wrote:<br>
>>><br>
>>> On 01/04/16 12:55, Joel Sherrill wrote:<br>
>>><br>
>>> On SPARC/SIS, the main lesson I learned is that if the executable<br>
>>> dropped to something ridiculously small, then something was<br>
>>> broken. I<br>
>>> had one iteration where hello.exe had 48 bytes of code. :)<br>
>>><br>
>>><br>
>>> Nice work.<br>
>>><br>
>>><br>
>>> That much was pretty obvious. Why was a problem. :)<br>
>>><br>
>>><br>
>>> Any thoughts on how to catch breakages on BSPs we can only link?<br>
>>><br>
>>><br>
>>> Can you get a suitable list of functions that must be present in<br>
>>> the executable and check they are present with nm?<br>
>>><br>
>>><br>
>>> It should be simple if the breakage is between the entry point and the<br>
>>> rest of the BSP. If hello does not include bsp_start() or<br>
>>> rtems_initialize_data_structures(), then it is known to be broken. This is<br>
>>> what broke on sis -- the first 16 instructions of the start code had no<br>
>>> dependency on anything else. So the linkages were satisfied and nothing else<br>
>>> pulled in. :)<br>
>>><br>
>>> I think this is a good thing to try to sweep in for 4.12 since<br>
>>> we can<br>
>>> easily check 4.11 vs 4.12 for breakages on specific BSPs.<br>
>>><br>
>>><br>
>>> So this is a once only check and not something we always check for?<br>
>>><br>
>>><br>
>>> Should be one time only. If the linkage between the start code and C code<br>
>>> is correct, it will stay correct. Once you get to C code, everything should<br>
>>> be magically correct.<br>
>>><br>
>>> I think this is simple enough in principle where it could be written up<br>
>>> as a series of GCI tasks. One task per BSP given the amount of time. It<br>
>>> isn't much editing but I would want<br>
>>><br>
>>> (1) patch to make/custom/XXX.cfg<br>
>>><br>
>>> (2) the commit message to include:<br>
>>> + base size for some tests like hello and ticker (same on all BSPs)<br>
>>> + new size for the same tests<br>
>>><br>
>>> (3) Confirmation with hello.num posted to GCI task so we can see the<br>
>>> symbols ourselves. But they should have checked it.<br>
>>><br>
>>> OTOH, one of us could probably sweep the argument changes into the custom<br>
>>> files quickly, my build scripts capture the size of the tests already, and<br>
>>> we are used to scripting and automated passes. Maybe I should play the next<br>
>>> couple of weeks. If someone wants to help, it would be nice to have some.<br>
>><br>
>><br>
>> I am in favour to enable this for all BSPs. Basically the linker scripts<br>
>> must have the KEEP () directive for the relevant sections. So, for a symbol<br>
>> test we should pick up one using the network stack and one using a global<br>
>> C++ constructor.About 60 BSPs have test linkage failures now due to size<br>
>> overflows. I see this as either edit .tcfg files and ignore tests which<br>
>> could actually fit with per section magic or edit the .cfg file and move<br>
>> forward.<br>
><br>
> One question is about the approach for bsp families with many variants and a<br>
> .inc file. It is easy to add the options to the .inc file and cover all<br>
> variants. Is that OK with everyone? It sure reduces the effort.<br>
><br>
> FWIW the SPARC bsps broke due to a missing dependency from the start code<br>
> not C++ or the linker set. This is more what I am concerned about. The ones<br>
> you mentioned should be easily checked with a grep on linker scripts.<br>
><br>
>> Do we really have to patch all the XXX.cfg files? Maybe wait until we have<br>
>> a new build system and add this to a common place?<br>
><br>
> At the moment, I can edit ~60 .tcfg or not that many more .cfg/.inc files<br>
> and likely solve the problem. I lean to the long-term solution. I don't see<br>
> waiting.<br>
><br>
> Looking at it another way, this was trialed in 4.11 with sparc BSPs.<br>
> Historically, we have precedence for improving some BSPs in one release and<br>
> sweeping something in place in the next. Makes sense to do this from that<br>
> perspective.<br>
><br>
</div></div>I say write this up as GCI tasks. Probably sweep the linkcmds first to<br>
add KEEP directives for each architecture. Then, each architecture can<br>
be converted to *-sections as a task. Functional validation should be<br>
performed with a simulator where possible, and RTEMS Tester should be<br>
used if available.<br>
<br></blockquote><div><br></div><div>I will try to get to this. We also could use one for deleting the m68k/idp BSP</div><div>and a ticket.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
It might be good to create GCI tasks for students to get RTEMS Tester<br>
working for a few simulator targets that are supported?<br>
<span class="im HOEnZb"><br></span></blockquote><div><br></div><div>I could be wrong but I think I created them for all gdb based simulators.</div><div>There is unlikely much low hanging fruit.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="im HOEnZb">
><br>
> --joel<br>
><br>
><br>
>> --<br>
>> Sebastian Huber, embedded brains GmbH<br>
>><br>
>> Address : Dornierstr. 4, D-82178 Puchheim, Germany<br>
>> Phone : <a href="tel:%2B49%2089%20189%2047%2041-16" value="+4989189474116">+49 89 189 47 41-16</a><br>
>> Fax : <a href="tel:%2B49%2089%20189%2047%2041-09" value="+4989189474109">+49 89 189 47 41-09</a><br>
>> E-Mail : <a href="mailto:sebastian.huber@embedded-brains.de">sebastian.huber@embedded-brains.de</a><br>
>> PGP : Public key available on request.<br>
>><br>
>> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.<br>
>><br>
><br>
><br>
</span><div class="HOEnZb"><div class="h5">> _______________________________________________<br>
> devel mailing list<br>
> <a href="mailto:devel@rtems.org">devel@rtems.org</a><br>
> <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
</div></div></blockquote></div><br></div></div>