Details
- Reviewers
echristo
Diff Detail
Event Timeline
There was talk about a diagnostic for targets that don't support split dwarf. Did you decide not to do that?
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.
objcopy's default behavior on seeing an unrecognized switch is to dump its entire help text.
That's not what I'd call user-friendly.
*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.
--paulr
From: cfe-commits-bounces@cs.uiuc.edu [mailto:cfe-commits-bounces@cs.uiuc.edu] On Behalf Of David Blaikie
Sent: Saturday, March 21, 2015 2:25 PM
To: reviews+D8484+public+374fa8dd1089857c@reviews.llvm.org
Cc: llvm cfe
Subject: Re: [PATCH] Allow -gsplit-dwarf for all ELF targets, not just Linux
Enable -gsplit-dwarf explicitly for FreeBSD as well - no consensus for the previous patch enabling for all ELF targets at present.
WFM. if the condition gets any more complicated it should be factored out into a helper function.
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).
Allowed for all ELF OSes as of
commit ee957e045f526ce45d24b0f081f277262c3da43d
Author: Fangrui Song <i@maskray.me>
Date: Thu Mar 28 08:24:00 2019 +0000
[Driver] Allow -gsplit-dwarf on ELF OSes other than Linux and Fuchsia
In gcc, -gsplit-dwarf is handled in gcc/gcc.c as a spec
(ASM_FINAL_SPEC): objcopy --extract-dwo + objcopy --strip-dwo. In
gcc/opts.c, -gsplit_dwarf has the same semantic of a -g. Except for the
availability of the external command 'objcopy', nothing precludes the
feature working on other ELF OSes. llvm doesn't use objcopy, so it doesn't
have to exclude other OSes.
llvm-svn: 357150