[GR-41359] Ninja: Use relativ path for project path, so that -fdebug-prefix-map= doesn't mess up the file name attribute

[lewurm]

This will change the gcc invocation from:

$ gcc [...] \
    -fdebug-prefix-map=/home/lewurm/work/graal=/graal \
    -fdebug-prefix-map=/home/lewurm/.mx/jdks/labsjdk-ce-17-jvmci-22.3-b02=labsjdk-ce-17-jvmci-22.3-b02 \
    [...] \
    /home/lewurm/work/graal/substratevm/src/com.oracle.svm.native.libchelper/src/cpuid.c \
    -o src/cpuid.o

to

$ gcc [...] \
    -fdebug-prefix-map=/home/lewurm/work/graal=graal \
    -fdebug-prefix-map=/home/lewurm/.mx/jdks/labsjdk-ce-17-jvmci-22.3-b02=labsjdk-ce-17-jvmci-22.3-b02 \
    [...] \
    ../../../../src/com.oracle.svm.native.libchelper/src/cpuid.c \
    -o src/cpuid.o

And this is how the DWARF information changes, before:

$
[...]
0x0000000b: DW_TAG_compile_unit
              DW_AT_name    ("graal/substratevm/src/com.oracle.svm.native.libchelper/src/cpuid.c")
              DW_AT_comp_dir    ("graal/substratevm/mxbuild/darwin-aarch64/com.oracle.svm.native.libchelper/aarch64")
[...]
0x00000032:   DW_TAG_subprogram
                DW_AT_low_pc    (0x00000000000000b8)
                DW_AT_high_pc   (0x0000000000000228)
                DW_AT_name  ("checkCPUFeatures")
                DW_AT_decl_file ("graal/substratevm/mxbuild/darwin-aarch64/com.oracle.svm.native.libchelper/aarch64/graal/substratevm/src/com.oracle.svm.native.libchelper/src/cpuid.c")
                DW_AT_decl_line (772)

After:

$
[...]
0x0000000b: DW_TAG_compile_unit
              DW_AT_name    ("../../../../src/com.oracle.svm.native.libchelper/src/cpuid.c")
              DW_AT_comp_dir    ("graal/substratevm/mxbuild/darwin-aarch64/com.oracle.svm.native.libchelper/aarch64")
[...]
0x00000032:   DW_TAG_subprogram
                DW_AT_low_pc    (0x00000000000000b8)
                DW_AT_high_pc   (0x0000000000000228)
                DW_AT_name  ("checkCPUFeatures")
                DW_AT_decl_file ("graal/substratevm/mxbuild/darwin-aarch64/com.oracle.svm.native.libchelper/aarch64/../../../../src/com.oracle.svm.native.libchelper/src/cpuid.c")
                DW_AT_decl_line (772)
[...]

For what it's worth gdb is able to deal with it (it seems to fallsback to DW_AT_name if DW_AT_decl_file does not exist, see strace log below), but lldb needs a proper path for DW_AT_decl_file.

strace output of gdb, before:

newfstatat(AT_FDCWD, "graal/substratevm/mxbuild/linux-aarch64/com.oracle.svm.native.libchelper/aarch64/graal/substratevm/src/com.oracle.svm.native.libchelper/src/cpuid.c", 0xfffffc3b5228, 0) = -1 ENOENT (No such file or directory)
newfstatat(AT_FDCWD, "/home/lewurm/work/graal/substratevm/src/com.oracle.svm.native.libchelper/src/cpuid.c", {st_mode=S_IFREG|0664, st_size=25615, ...}, 0) = 0
openat(AT_FDCWD, "/home/lewurm/work/graal/substratevm/src/com.oracle.svm.native.libchelper/src/cpuid.c", O_RDONLY|O_CLOEXEC) = 12

After:

newfstatat(AT_FDCWD, "graal/substratevm/mxbuild/linux-aarch64/com.oracle.svm.native.libchelper/aarch64/../../../../src/com.oracle.svm.native.libchelper/src/cpuid.c", {st_mode=S_IFREG|0664, st_size=25615, ...}, 0) = 0
openat(AT_FDCWD, "graal/substratevm/mxbuild/linux-aarch64/com.oracle.svm.native.libchelper/aarch64/../../../../src/com.oracle.svm.native.libchelper/src/cpuid.c", O_RDONLY|O_CLOEXEC) = 12

[lewurm]

FYI @adinn. I noticed that while trying to make lldb happy on macOS (note that the commit message talks about lldb on Linux though).

[adinn]

Hi @lewurm As far as I can tell (which is, perhaps, not very far) that looks to be doing the right thing. However, I'm not really sure, nor am I sure whether there is any requirement or justification for me to comment. This looks to be an issue with the DWARF output generated by gcc. Is there some interaction with the Java-derived DWARF info at play here? Or does this relate to setting a gdb directory path to the C sources? Either way does this require a code or docs change?

[lewurm]

Thanks for your comment @adinn. No action from you needed, I just wanted to let you know 🙂

You are right, it's purely an issue with gcc, but it affects the native-image debugging experience if some native bits of the VM itself are being inspected (for example this checkCPUFeatures() function from the commit message). gdb has proper fallbacks in place if DW_AT_decl_file doesn't make sense, but lldb doesn't attempt to guess.

I think no one has seriously tried to use lldb instead of gdb, so we don't need to put warnings into the docs yet.

The reason I'm trying to make lldb happy is that 1. building gdb on macOS is a pain and 2., more critical, no macOS/AArch64 port of gdb exists yet.

[adinn]

@lewurm Ok, thanks for clarifying.

BTW, if you get to the point where you want/need Java DWARF for MacOS and need help migrating the current code to work with the Macho object format then I'll be very happy to provide advice on how to go about it or help diagnose any issues that turn up.