Many BSPs Fail to link CXX tests

Tue Jan 5 18:54:55 UTC 2016

On Tue, Jan 5, 2016 at 1:10 PM, Joel Sherrill <joel at rtems.org> wrote:
>
> 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.
>
I say write this up as GCI tasks. Probably sweep the linkcmds first to
add KEEP directives for each architecture. Then, each architecture can
be converted to *-sections as a task. Functional validation should be
performed with a simulator where possible, and RTEMS Tester should be
used if available.

It might be good to create GCI tasks for students to get RTEMS Tester
working for a few simulator targets that are supported?

>
> --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.
>>
>
>
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel