[llvm-bugs] [Bug 40276] New: Change in behavior of -split-dwarf-file from Clang 6

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=40276

            Bug ID: 40276
           Summary: Change in behavior of -split-dwarf-file from Clang 6
           Product: clang
           Version: 7.0
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Driver
          Assignee: unassignedclangbugs at nondot.org
          Reporter: aaronpuchert at alice-dsl.net
                CC: llvm-bugs at lists.llvm.org, neeilans at live.com,
                    richard-llvm at metafoo.co.uk

We use Clang's frontend option -split-dwarf-file to make the generated object
file link to a different filename than we use for compilation, but this doesn't
work any longer.

Our distributed build system compiles the preprocessed source on clients and
then sends that to another machine, where we compile it with
-fdebug-compilation-dir /client/src/dir and -split-dwarf-file
/client/path/to/dwarf/file to make sure that tools on the client will find the
DWO file, once we have sent them back.

This used to work until Clang 6, but with Clang 7 the argument to
-split-dwarf-file is also used as actual output filename. To reproduce the
change, create a file test.cpp (content doesn't matter as long as it compiles)
and run

$ clang++ -c -g -gsplit-dwarf -Xclang -split-dwarf-file -Xclang foo.dwo -o
test.o test.cpp
$ objdump -Ws test.o

test.o:     file format elf64-x86-64

Contents of the .debug_str section:

  0x00000000 666f6f2e 64776f00 2f686f6d 652f6161 foo.dwo./home/aa
  0x00000010 726f6e00                            ron.

This is the same for both Clang 6 and 7. But Clang 6 creates test.dwo alongside
test.o, while Clang 7 creates foo.dwo. It becomes a problem when instead of
foo.dwo we take a path that doesn't exist on the build host:

$ clang++-7.0 -c -g -gsplit-dwarf -Xclang -split-dwarf-file -Xclang
client/dir/foo.dwo -o test.o test.cpp
error: unable to open output file 'client/dir/foo.dwo': 'No such file or
      directory'
1 error generated.

The change that caused this is https://reviews.llvm.org/D47093.

No I understand that frontend-only (-cc1) options are not guaranteed to be
stable across releases, but maybe this change wasn't intentional. If it was
intentional, we still need a way to write a different file name into the object
file than what the actual file on the disk is called, because we move/rename
both object and dwo file to a different machine. We can somewhat handle that
via -fdebug-compilation-dir, but that doesn't completely solve our problem as
the build hosts rename files to avoid clashes.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20190110/04685012/attachment.html>