Many BSPs Fail to link CXX tests

[Sebastian Huber]

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?

-- 
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.