On Tue, Jan 5, 2016 at 5: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. > > 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? > That works if we know all work. To validate incrementally the best approach is to go through the .cfg files.
> -- > 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
