scott.linder added inline comments.

================
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:
> 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.


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

Reply via email to