Sounds like just turning it on for everyone & letting objcopy print a
failure that it doesn't support the flag would be reasonable? No need for a
particular error from clang. But I dunno.
*I* wouldn't, but licensees love to try stuff out even if we don't claim it
works. Currently, adding -gsplit-dwarf to a command line silently has
no effect. With your patch, I get:
clang.exe: error: unable to execute command: program not executable
which will inevitably cause a support call and cost us time and effort.
I'd prefer to preserve the "silently has no effect" behavior, at least until
we are able to support this properly.
30 years of delivering enterprise software tells me this:
If a switch you don't claim to support does nothing, nobody will complain. (Unless they're looking for an excuse to jerk your chain.)
If a switch you don't claim to support says "sorry, that switch is not supported" nobody will complain, period.
If a switch you don't claim to support says "program not executable" you WILL hear about it.
I'd be happiest with the second case, and fine with the first case. The third case is unacceptable.
From: firstname.lastname@example.org [mailto:email@example.com] On Behalf Of David Blaikie
Sent: Saturday, March 21, 2015 2:25 PM
Cc: llvm cfe
Subject: Re: [PATCH] Allow -gsplit-dwarf for all ELF targets, not just Linux
Well, in this case I would prefer to black list systems that want to ignore the option. I think that's a far better approach. While I don't agree with the reasoning of the PS4 guys, I can understood the pain. But it should be applied to other systems as it violates POLA.
A black list that excluded PS4 or a white list that didn't include PS4 would be equally fine.
Emitting the "not supported for this target" diagnostic would be gravy.
While I don't agree with the reasoning of the PS4 guys, I can understood the pain. But it should be applied to other systems as it violates POLA.
Not clear what "it" you are referring to here. But a diagnostic that says "program not executable" seems more astonishing than either of the alternatives.
We could add a toolchain flag whether objcopy is supposed to exist. PS4 could set that to false, everything else to true. That would allow at least a proper error message for the PS4 case and whoever else cares. I think silently failing here is very bad as the option changes the behavior of clang (it is supposed to create another output file after all).