Many BSPs Fail to link CXX tests

[Gedare Bloom]

On Sun, Jan 3, 2016 at 9:47 PM, Joel Sherrill <joel at rtems.org> wrote:
>
>
> On Sun, Jan 3, 2016 at 8:26 PM, Chris Johns <chrisj at rtems.org> wrote:
>>
>> On 01/04/16 12:55, Joel Sherrill wrote:
>>>
>>> On SPARC/SIS, the main lesson I learned is that if the executable
>>> dropped to something ridiculously small, then something was broken. I
>>> had one iteration where hello.exe had 48 bytes of code. :)
>>
>>
>> Nice work.
>>
>
> That much was pretty obvious. Why was a problem. :)
>>>
>>>
>>> Any thoughts on how to catch breakages on BSPs we can only link?
>>>
>>
>> Can you get a suitable list of functions that must be present in the
>> executable and check they are present with nm?
>>
>
> It should be simple if the breakage is between the entry point and the rest
> of the BSP. If hello does not include bsp_start() or
> rtems_initialize_data_structures(), then it is known to be broken. This is
> what broke on sis -- the first 16 instructions of the start code had no
> dependency on anything else. So the linkages were satisfied and nothing else
> pulled in. :)
>
Such a list should be easy enough to create by building every BSP and
creating a list of functions appearing in every one (known to run).

>>>
>>> I think this is a good thing to try to sweep in for 4.12 since we can
>>> easily check 4.11 vs 4.12 for breakages on specific BSPs.
>>
>>
>> So this is a once only check and not something we always check for?
>>
>
> Should be one time only. If the linkage between the start code and C code is
> correct, it will stay correct. Once you get to C code, everything should be
> magically correct.
>
> I think this is simple enough in principle where it could be written up as a
> series of GCI tasks. One task per BSP given the amount of time. It isn't
> much editing but I would want
>
> (1) patch to make/custom/XXX.cfg
>
> (2) the commit message to include:
>     + base size for some tests like hello and ticker (same on all BSPs)
>     + new size for the same tests
>
> (3) Confirmation with hello.num posted to GCI task so we can see the symbols
> ourselves. But they should have checked it.
>
> OTOH, one of us could probably sweep the argument changes into the custom
> files quickly, my build scripts capture the size of the tests already, and
> we are used to scripting and automated passes.  Maybe I should play the next
> couple of weeks. If someone wants to help, it would be nice to have some.
>
>>
>> Chris
>
>
>
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel