Ping?
https://gcc.gnu.org/ml/gcc-patches/2019-05/msg00695.html
I originally hesitated adding a space, as Martin suggested, so that
argv[0] still obviously looked like a single arg. But I'm not opposed to
changing that. He's also right that the errors one can get from failing
to spawn are very implementor-speak, as Sandra would say. But that's
not addressed here.
On 5/14/19 10:02 AM, Nathan Sidwell wrote:
This patch nadgers the driver's subprocess names to include the driver
name. It results in more informative error messages. For instance,
rather than:
>./xg++ -B./ frob.cc -c -fdump-tree-nope
cc1plus: error: unrecognized command line option '-fdump-tree-nope'
we get:
>./xg++ -B./ frob.cc -c -fdump-tree-nope
xg++(cc1plus): error: unrecognized command line option
'-fdump-tree-nope'
Thereby cluing the user into this being a compiler error. (When this
error is buried inside a build log, the poor user can be more confused
as to what this cc1plus thing might be).
I achieve this by taking advantage of the subprocess spawning taking
separate arguments for the program to exec, and the argv[0] value passed
to that program. Because subprocesses can use argv[0] to locate
themselves I propagate the directory name, so that remains as before.
When using valgrind, this substitution is not performed, because
valgrind relies on argv[0] being the program pathname.
The -v output is unaffected, as that is emitted before altering argv[0].
argv[0] is also restored after spawning.
This then allows us to elide process_command's check of whether the
input file exists. That's optimizing for failure, but I suspect is
desired merely to avoid an error of the form:
cc1plus: fatal error: frob.cc: No such file or directory
As you can see process_command does some special handling for lto &
@files, which is kind of icky and now goes away. We get:
xg++(cc1plus): fatal error: frob.cc: No such file or directory
Thoughts? Ok? Stupid idea?
nathan
--
Nathan Sidwell
