[Toybox] [Issue] - single build

[Rob Landley]

On 09/09/14 23:44, Rob Landley wrote:
> On 09/04/14 22:32, Ashwini Sharma wrote:
>> Hi Rob,
>>
>> When doing a single build toy_list is populated with the command to be built
>> and all it __aliases__ in the chronological ascending order.
> 
> I've checked in a partial upgrade to the infrastructure, it now
> determines which C files to build by grepping for the NEWTOY/OLDTOY
> macros that enable the commands in question.
> 
> However, some commands depend on other commands to be enabled. In some
> cases the "depends on" can be removed from kconfig, but in others (such
> as cp/mv/install) one command calls another command's infrastructure
> across flag contexts. Or in the case of id/groups/logname they all work
> in ID's flag context.

To clarify:

The issue here is that if a command is disabled in kconfig, its FLAG_*
macros are all #defined to 0, so the compiler's constant propagation and
dead code elimination see something like:

  if (toys.optflags & FLAG_X) blah();

See that FLAG_X is 0, thus anything & FLAG_X must be 0, thus if (0) and
it can optimize away the call to blah(). (This is intentional to allow
configured-out code to drop out without #ifdefs, but it does mean that
shared infrastructure can have functionality removed by kconfig if it
depends on a specific command's flags.)

(Even tinycc has _this_ level of constant propogation and optimization,
so I feel I can rely on the compiler being able to do that much.)

But if I resolve these dependencies by _enabling_ more than one command
when doing a single build, the toy_list[] array isn't guaranteed to be
length 1, thus I can't just grab the first entry unconditionally and
avoid the multiplexer code.

One fix is to work out a static offset to the command I want, but that
has the downside that the other command_main() functions would have
function pointers listed in toy_list[] and even though those function
pointers are never used (the only user of toy_list[] dereferences a
single static offset to get the one entry it's interested in), the
compiler may not be smart enough to know it can optimize out those other
command_main() functions and the code only they ever call.

So... unresolved design issue I'm still chipping away at. The single
builds weren't a priority before, so I didn't work out the details...

Rob

(Probably what I should do is separate toy_list[] generation from flag
generation, so I can guarantee a single element toy_list[] when doing
single builds, even if more than one kconfig entry is enabled as far as
flags.h is concerned. But that's not for _this_ release...)

 1410365656.0