Many BSPs Fail to link CXX tests

Tue Jan 5 19:10:09 UTC 2016

On Tue, Jan 5, 2016 at 12:54 PM, Gedare Bloom <gedare at rtems.org> wrote:

> 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.
>
>
I will try to get to this. We also could use one for deleting the m68k/idp
BSP
and a ticket.

> It might be good to create GCI tasks for students to get RTEMS Tester
> working for a few simulator targets that are supported?
>
>
I could be wrong but I think I created them for all gdb based simulators.
There is unlikely much low hanging fruit.

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