[PATCH] D149193: [Driver] Add -dumpdir and change -gsplit-dwarf .dwo names for linking

[Fangrui Song via Phabricator via cfe-commits]

MaskRay added a comment.

In D149193#4300501 <https://reviews.llvm.org/D149193#4300501>, @phosek wrote:

> Do we have any way to check if there are projects out there that use `-dumpbase`? It shouldn't be too difficult to support it, but we should find out first if it's needed.

I spot checked the very few items on https://sourcegraph.com/search?q=context:global+-dumpbase+&patternType=standard&sm=1&groupBy=repo and they don't like genuine use cases.

I think the main use case for `-dumpbase` is to entirely control the auxiliary file for `-c` and `-S`, but the addition of `-dumpbase` doesn't seem very useful to me...

  gcc -c -g -gsplit-dwarf d/a.c -dumpdir f/ -dumpbase aa   # f/aa.dwo instead of f/a.dwo



================
Comment at: clang/lib/Driver/Driver.cpp:3884
+          nullptr, getOpts().getOption(options::OPT_dumpdir),
+          Args.MakeArgString(Args.getLastArgValue(options::OPT_o, "a") + "-"));
+      Arg->claim();
----------------
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 :)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D149193/new/

https://reviews.llvm.org/D149193