On Sun, Jan 3, 2016 at 9:47 PM, Joel Sherrill <j...@rtems.org> wrote: > > > On Sun, Jan 3, 2016 at 8:26 PM, Chris Johns <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. :) > Such a list should be easy enough to create by building every BSP and creating a list of functions appearing in every one (known to run).
>>> >>> 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. > >> >> Chris > > > > _______________________________________________ > 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
