buildpaths generated into .debug_str

[kraj]

This attached example is emitting absolute build time paths into .debug_str section when compiled with Clang 16.0.1
The path is computed from source file location specified on cmdline. This seems to work ok when -fno-integrated-asm is used.

Here is the strings output and also readelf output.

% strings a.o|grep /mnt
(lambda at /mnt/b/yoe/master/build/tmp/work/core2-64-yoe-linux-musl/libcereal/1.3.2+gitAUTOINC+ebef1e9298-r0/build/unittests/a.cpp:46197:11)
~(lambda at /mnt/b/yoe/master/build/tmp/work/core2-64-yoe-linux-musl/libcereal/1.3.2+gitAUTOINC+ebef1e9298-r0/build/unittests/a.cpp:46197:11)

% readelf -x 4271 a.o | grep mnt
  0x001bf100 6d626461 20617420 2f6d6e74 2f622f79 mbda at /mnt/b/y

test.tar.gz

[dwblaikie]

What's the bug? If you want portable object files DWARF doesn't do that by default in many ways (all the filenames in .debug_line/.debug_line_str, for instance?)

You can use -fdebug-compilation-dir or -fdebug-prefix-map to rename the root directory in some way that might be suitable for your needs.

[kraj]

What's the bug? If you want portable object files DWARF doesn't do that by default in many ways (all the filenames in .debug_line/.debug_line_str, for instance?)

You can use -fdebug-compilation-dir or -fdebug-prefix-map to rename the root directory in some way that might be suitable for your needs.

I have tried those options do not help that’s the issue

[dwblaikie]

Could you provide a small repro? (example source, sufficiently minimized, command line, and dumping that shows the problem)

At least on my small examples, those flags seem to do what's required/desired.

[dankm]

Could you provide a small repro? (example source, sufficiently minimized, command line, and dumping that shows the problem)

Take a look at the test case I created for D149272. Another example is line 24 in libcxx/src/barrier.cpp.

At least on my small examples, those flags seem to do what's required/desired.

It's a pretty odd corner case. It happens when a constructor is created for a nested anonymous record type. I've only encountered it by accident, and was only able to isolate it earlier today.

[dwblaikie]

Is D149272 intended to be a fix for this bug? Would be good to mention it in the review, then, to cross-link these things.

[dankm]

Yes, D149272 is for this bug. I noticed it independently of @kraj. I'll add comments to that effect in the review.

[dankm]

Fix in review: https://reviews.llvm.org/D149272

[llvmbot]

@llvm/issue-subscribers-clang-frontend