On 2024-02-12 10:00, Richard Biener wrote:
GCC driver support is then to the extent identifying the inputs and the outputs.
We already have -MM to generate a list of non-system dependencies, so
gcc should be able to pass on inputs to the tool, which could then map
those files (and the system headers directory) into the sandbox before
invocation. The output file could perhaps be enforced as having to be a
new one, i.e. fail if the target is already found.
I'm not sure a generic utility can achieve this unless the outputs need to be
retrieved from somewhere else (not "usual" place when invoking un-sandboxed).
Even the driver doesn't necessarily know all files read/written.
So I suppose better defining of the actual goal is in order.
gcc -sandboxed -O2 -c t.ii -fdump-tree-all
what should this do? IMO invoked tools (gas, cc1plus) should be restricted
to access the input files. Ideally the dumps would appear where they
appear when not sandboxed but clearly overwriting existing files would be
problematic, writing new files not so much, but only to the standard (or
specified) auxiliary output file paths.
Couldn't we get away with not having to handle dump files? They don't
seem to be sensitive targets.
Thanks,
Sid
