On Tue, Jan 5, 2016 at 12:54 PM, Gedare Bloom <ged...@rtems.org> wrote:
> On Tue, Jan 5, 2016 at 1:10 PM, Joel Sherrill <j...@rtems.org> wrote: > > > > On Jan 5, 2016 4:35 AM, "Sebastian Huber" > > <sebastian.hu...@embedded-brains.de> wrote: > >> > >> > >> > >> On 04/01/16 03:47, Joel Sherrill wrote: > >> > >>> > >>> > >>> On Sun, Jan 3, 2016 at 8:26 PM, Chris Johns <chr...@rtems.org > >>> <mailto:chr...@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.hu...@embedded-brains.de > >> PGP : Public key available on request. > >> > >> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. > >> > > > > > > _______________________________________________ > > devel mailing list > > devel@rtems.org > > http://lists.rtems.org/mailman/listinfo/devel >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
