Many BSPs Fail to link CXX tests

[Gedare Bloom]

On Tue, Jan 5, 2016 at 5:35 AM, Sebastian Huber
<sebastian.huber at embedded-brains.de> wrote:
>
>
> On 04/01/16 03:47, Joel Sherrill wrote:
>>
>>
>>
>> On Sun, Jan 3, 2016 at 8:26 PM, Chris Johns <chrisj at rtems.org
>> <mailto: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. :)
>>
>>         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.
>
>
> I am in favour to enable this for all BSPs. Basically the linker scripts
> must have the KEEP () directive for the relevant sections. So, for a symbol
> test we should pick up one using the network stack and one using a global
> C++ constructor.
>
> Do we really have to patch all the XXX.cfg files? Maybe wait until we have a
> new build system and add this to a common place?
>
That works if we know all work. To validate incrementally the best
approach is to go through the .cfg files.

> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax     : +49 89 189 47 41-09
> E-Mail  : sebastian.huber at embedded-brains.de
> PGP     : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
>
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel