Community
Participate
Working Groups
Created attachment 198695 [details] email thread that lead to this bug See attached email for details about the original problem. What follows is a description of the root cause and possible solutions: In addition to parsing the script, the live config session also discovers all the modules and instances that have have been assigned to JavaScript variables. We use this to correlate the full picture we pull from the live config with the partial picture that we parse from the script. For example for instances in particular, we use the JavaScript name to pair up the Mod.create() call in the script with the resulting "Mod.Instance#XX" read from the config session. This bug is because we have inconsistent definitions of "module is used" in the Java code due to historical cruft. The "lock" icon is strictly looking at the parsed script (ProblemLabelDecorator.java, decorateLabel(), line 93) and gets the right answer. The "Use BIOS" menu is looking at a looser definition that considers variables scraped from the config session too (ConfigScriptFile.java, isEditable(), line 1284) and gets the wrong answer. The immediate cause is that some module is doing "BIOS = xdc.useModule("ti.sysbios.BIOS");" without a "var" statement. This is probably somewhere inside BIOS itself, in a module's module.xs file. For example, family.msp430.TimestampProvider.xs is one, timers.dmtimer.TimestampProvider.xs is another. This is making the BIOS module visible even though it's not used directly in the user's .cfg script. By the way to fix this, both of these files should add "var BIOS = null;" near the top of the file, same as in many other .xs files in BIOS. Until very recently (1-2 months ago) XGCONF incorrectly promoted "var" statements in the user's .cfg script to be JavaScript global variables. When run from the command line, these are local to a capsule, not globals. This is fixed now, but part of the historical cruft is that we are still searching for JavaScript global variables assigned to modules or instances. One solution is to just remove this code (ConfigProvider.xs, function loadCfgModel(), line 133) and search only the .cfg script capsule. This is a little bit aggressive, because it needlessly breaks hand-written user config scripts that still use global JavaScript variables, i.e. "myInst = MyMod.create();" instead of "var myInst = MyMod.create();". My preferred solution is to fix the inconsistency between the lock icon and the "Use BIOS" menu. This can be done by fixing ConfigScriptFile.isEditable(). There's a large comment in this method talking about a known problem. Specifically we should fix ConfigScriptFile.getScriptNode(), so that it reliably returns a script node if one exists, then the trouble-making hack in isEditable() can be removed.
