On Nov 12, 2014, at 2:55 AM, Thomas Schwinge <tho...@codesourcery.com> wrote: > There is no mechanism in DejaGnu to pass environment variables to remote > boards (which we're using in internal testing), and we currently use that > to circle through available accelerators/libgomp plugins
So, two thoughts come to mind. In my target, I wire up env and in my simulator, I push all of the environment from the host into the target. Works very nicely, I can bootstrap gcc and binutils on my target. Total line count to do this is fairly trivial. Once done, then all the usual environment adjusting that one can do in tcl is reflected on the target. Or, you can put in code that will communicate the bits over to the target. When commands are executed, usually we are pushing them into shells, and in shells, you can do: env1=value1 env2=value2 command arg1 arg2 and push as many variables over that you want. Just need an api to add/manage what variables you want to actively push. If you don’t have a shell, you still need some way to communicate the variables over. Ultimately this will have to be put into the board file and then the abi can use that interface to move the variables. I don’ think there are existing ways to do this. I like the first, and that’s fine for testing on software simulators with lots of memory. On actual target hardware with limited memory, it would be less appropriate. The second, might require a dejagnu update to it work. Another thought, if you have an argument to the program you want to run, —env, that can place environment variables into that program, you can then just add —env args to the command line too, and it will put them into the environment directly. Benefit, no dejagnu mods or updates. Easy to understand and audit (env variables otherwise kinda disappear, making flaws in them harder to see).
