dblaikie added a comment. > I agree that for most(all?) split DWARF users will not see any difference > since they always use -c -o and don't combine compilation and linking in one > command.
Given that, I'm not sure that this is worth implementing, but if it suits you I guess. ================ Comment at: clang/lib/Driver/Driver.cpp:3884 + nullptr, getOpts().getOption(options::OPT_dumpdir), + Args.MakeArgString(Args.getLastArgValue(options::OPT_o, "a") + "-")); + Arg->claim(); ---------------- MaskRay wrote: > scott.linder wrote: > > MaskRay wrote: > > > dblaikie wrote: > > > > would be nice to have this "a" derive from wherever we hardcode "a.out" > > > > as the default output rather than independently hardcoded here? > > > > > > > > & what does GCC do when the `-o` value has a `.` in it? (if you use `-o > > > > a.out` do you get the same `a-x.dwo` behavior, or do you get > > > > `a.out-x.dwo`?) > > > We can use `llvm::sys::path::stem(getDefaultImageName())`, but I feel > > > that this just complicates the code. > > > The default is `a.out` or `a.exe`. If a downstream platform decides to > > > deviate and use another filename, say, `b.out`. We will use `-dumpdir b-` > > > on this platform and `-dumpdir a-` on everything else. I think they will > > > likely be fine with `a-` even if they don't use `a` as the stem name of > > > the default image... > > > > > > GCC generally doesn't special case `.` in `-o` for linking, but the > > > `a.out` filename is different. > > > > > > ``` > > > gcc -g -gsplit-dwarf d/a.c.c -o e/x.out # e/x.out-a.dwo > > > gcc -g -gsplit-dwarf d/a.c.c -o e/a.out # e/a-a.dwo > > > ``` > > > > > > I think Clang should not special case `a.out`. > > GCC distinguishes between "dump" and "auxiliary" outputs, and in this case > > I think the "dump" outputs retain the basename-suffix (i.e. you get > > a.out<dumppfx>) whereas "auxiliary" outputs first strip the basename-suffix > > (i.e. you get a<dumppfx>). The basename-suffix itself can be specified > > explicitly via -dumpbase-ext, but it is inferred by default. > > > > The naming for things adds to the for me: > > > > * `-dumpdir` doesn't specifically/exclusively specify a "directory", it > > just specifies a prefix > > * `-dumpbase-ext` only affects the output of non-dump, auxiliary files > > > > I do worry that being close-but-not-quite like GCC here will cause > > headaches for someone, but I am also not excited about implementing the > > complexity of the GCC options. > > ... I think the "dump" outputs retain the basename-suffix (i.e. you get > > a.out<dumppfx>) whereas "auxiliary" outputs first strip the basename-suffix > > (i.e. you get a<dumppfx>). > > Confirmed. > ``` > gcc -g -fdump-rtl-all -gsplit-dwarf d/a.c -o e/x.out > ls e/x.out-a.c.338r.dfinish e/x.out-a.dwo > ``` > > For dump output files, I think they all reside in developer options > (https://gcc.gnu.org/onlinedocs/gcc/Developer-Options.html) not intended to > be used by end users. They occasionally make incompatible changes in this > area as well, e.g. > https://gcc.gnu.org/pipermail/gcc-patches/2020-May/546009.html simplified > some rules. > > It seems that if we just implement `-dumpdir`, we have gotten the good parts > and we are probably done :) > We can use llvm::sys::path::stem(getDefaultImageName()), but I feel that this > just complicates the code. I think it'd be a bit better this way - otherways "a" looks pretty arbitrary. Is there some other reason it would be "a"? If it is derived from "a.out" I think having the code reflect that is helpful to the reader. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D149193/new/ https://reviews.llvm.org/D149193 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
