`llvm-dwp` doesn't have a default output file name, instead tries to write to ""

[cjdb]

Problem

llvm-dwp reports an error when given a simple program, regardless of compiler.

System info

• Current system: Debian
• Also observed on Ubuntu 24.04 with LLVM 19 from apt.llvm.org
• Also observed on Arch Linux

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/cjdb/opt/libexec/gcc/x86_64-pc-linux-gnu/15.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --enable-lto --prefix=/home/cjdb/opt --disable-nls --enable-languages=c,c++ --enable-gold --disable-multilib --disable-werror : (reconfigured) ../gcc/configure --enable-lto --prefix=/home/cjdb/opt --disable-nls --enable-gold --disable-multilib --disable-werror CC=gcc CFLAGS='-g0 -O3 -DNDEBUG' LDFLAGS=-fuse-ld=gold CXX=g++ CXXFLAGS='-g0 -O3 -DNDEBUG' --enable-languages=c,c++,lto --no-create --no-recursion
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.0 20240621 (experimental) (GCC)

$ clang -v
clang version 20.0.0git (/home/cjdb/projects/llvm-project/clang 135a1e90a3066f61ca741e9ebebfec79c9595ea5)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/cjdb/opt/bin
Found candidate GCC installation: /home/cjdb/opt/bin/../lib/gcc/x86_64-pc-linux-gnu/14.0.1
Found candidate GCC installation: /home/cjdb/opt/bin/../lib/gcc/x86_64-pc-linux-gnu/15.0.0
Selected GCC installation: /home/cjdb/opt/bin/../lib/gcc/x86_64-pc-linux-gnu/15.0.0
Candidate multilib: .;@m64
Selected multilib: .;@m64

$ llvm-dwp --version
LLVM (http://llvm.org/):
  LLVM version 20.0.0git
  Optimized build.

Examples

GCC

$ cat hello.cpp
#include <iostream>

int main()
{
  int a;
  std::cin >> a;
  std::cout << (a + 1) << '\n';
}
$ g++ -c -o hello.o hello.cpp -g -gsplit-dwarf
$ g++ -c -o hello.o hello.cpp -g -gsplit-dwarf -fuse-ld=lld
$ g++ -o hello hello.o -fuse-ld=lld
$ ./hello
10
11
$ llvm-dwp -e hello
while processing dwarf streamer init:
error: : No such file or directory

Clang

$ ls
hello  hello.cpp  hello.dwo  hello.o
$ rm hello hello.dwo hello.o
$ clang++ -c -o hello.o hello.cpp -g -gsplit-dwarf -fuse-ld=lld
clang++: warning: argument unused during compilation: '-fuse-ld=lld' [-Wunused-command-line-argument]
$ clang++ -o hello hello.o -fuse-ld=lld
$ ./hello
13
14
$ llvm-dwp -e hello
while processing dwarf streamer init:
error: : No such file or directory

Related issues

https://sourceware.org/bugzilla/show_bug.cgi?id=32032 Not related, just a coincidence.

[dwblaikie]

llvm-dwp doesn't have a default value for the output file name - so it's trying to write to a file named "". -o hello.dwp would address this, though presumably binutils dwp -e behavior defaults to <binary>.dwp and that could be implemented in llvm-dwp too

[cjdb]

Looking at the respective help menus, I see that the interfaces are quite different.

$ dwp --help
Usage: dwp [options] [file...]
  -h, --help               Print this help message
  -e EXE, --exec EXE       Get list of dwo files from EXE (defaults output to EXE.dwp)
  -o FILE, --output FILE   Set output dwp file name
  -v, --verbose            Verbose output
  --verify-only            Verify output file against exec file
  -V, --version            Print version number

Report bugs to <https://sourceware.org/bugzilla/>

$ llvm-dwp --help
OVERVIEW: merge split dwarf (.dwo) files

USAGE: llvm-dwp [options] <input files>

OPTIONS:
  -continue-on-cu-index-overflow=<value>
                default = continue, This turns an error when offset 
                                for .debug_*.dwo sections overfolws into a warning. = soft-stop, This produces a 
                                truncated but valid DWP file, discarding any DWO files that would not fit within 
                                the 32 bit/4GB limits of the format.
  -e <filename> Specify the executable/library files to get the list of *.dwo from.
  -help         Display this help
  -h            Alias for --help
  -o <filename> Specify the output file.
  -version      Display the version of this program

Perhaps we should try to bring them closer to parity?

[dwblaikie]

practically speaking most of the usage is just "dwp a.dwo b.dwo c.dwo -o abc.dwp" and "dwp -e a.exe -o a.dwp" which is mostly consistent - though, yeah, defaulting the output file name would probably be a useful convenience.

making sure help, version, and verbose work the same wouldn't be a bad thing, of course