Many BSPs Fail to link CXX tests

[Joel Sherrill]

On Jan 5, 2016 4: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.About 60 BSPs have test linkage failures now due to size
overflows. I see this as either edit .tcfg files and ignore tests which
could actually fit with per section magic or edit the .cfg file and move
forward.

One question is about the approach for bsp families with many variants and
a .inc file. It is easy to add the options to the .inc file and cover all
variants. Is that OK with everyone? It sure reduces the effort.

FWIW the SPARC bsps broke due to a missing dependency from the start code
not C++ or the linker set. This is more what I am concerned about. The ones
you mentioned should be easily checked with a grep on linker scripts.

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

At the moment, I can edit ~60 .tcfg or not that many more .cfg/.inc files
and likely solve the problem. I lean to the long-term solution. I don't see
waiting.

Looking at it another way, this was trialed in 4.11 with sparc BSPs.
Historically, we have precedence for improving some BSPs in one release and
sweeping something in place in the next. Makes sense to do this from that
perspective.


--joel


> --
> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20160105/6ca32a8e/attachment-0002.html>