CMake project generates incorrect DWARF source paths

[WasabiFan]

(Sorry for the CMake report, I know CMake isn't favored here 🙂)

I noticed source file discovery errors from debug tools while operating on ELFs built in my CMake-based project. The source paths resolve to nonexistent directories in e.g. GDB. As shown below the DWARF source paths are structured differently when I build the same project with CMake vs. SCons. I'm not sure what is correct/incorrect w.r.t. the DWARF spec but I assume it's bad metadata rather than a GDB bug.

Related: #558 (added the "ffile-prefix-map" to make source paths relative)

I need to set this aside for now so haven't gotten a chance to dig into what specifically is different about CMake's gcc invocation vs. SCons to have the below effect.

Commands I used for inspecting metadata:

objdump --debugging example > ../cmake_objdump.txt
gdb --nx -q -ex 'file ../../../../build/nucleo_f401re/blink/scons-release/blink.elf' -ex 'info sources' -ex 'quit' > ../scons_gdb_sources_dump.txt

objdump --debugging ../../../build/nucleo_f401re/blink/scons-release/blink.elf > scons_objdump.txt
gdb --nx -q -ex 'file example' -ex 'info sources' -ex 'quit' > ../cmake_gdb_sources_dump.txt

From the scons build, gdb's "info sources" outputs paths like this:

./modm/ext/printf/printf.c
./modm/src/modm/platform/uart/uart_hal_2.hpp

For the cmake build, the same paths look like this:

./build/modm/./modm/ext/printf/printf.c
./build/./modm/src/modm/platform/uart/uart_hal_2.hpp

The paths, even if canonicalized, aren't correct relative to any root directory as far as I can tell.

Looking at the DWARF metadata from objdump, I see the following from the scons build for that compilation unit:

    <2baf0>   DW_AT_name        : (indirect string, offset: 0x6fafd): modm/ext/printf/printf.c
    <2baf4>   DW_AT_comp_dir    : .

Meanwhile the cmake build looks like this:

    <f1de>   DW_AT_name        : (indirect string, offset: 0x6c1c9): ./modm/ext/printf/printf.c
    <f1e2>   DW_AT_comp_dir    : (indirect string, offset: 0x6c04d): ./build/modm

It looks to me like GDB is concatenating the comp_dir and name. (After some experimentation I think this is specific to relative "name" paths.) For the C file the path has a duplicated segment. The header doesn't have the duplicated segment. Regardless, neither source file should be under the "build" directory.

I did this test on an arbitrary example which I hacked to build with CMake for comparison. The changes are here: https://github.com/WasabiFan/modm/tree/a8d8b9a251f7fde85ace538eae9a9968a89c5102/examples/nucleo_f401re/blink

Full output from the commands shown earlier:

scons_gdb_sources_dump.txt
scons_objdump.txt
cmake_gdb_sources_dump.txt
cmake_objdump.txt

[salkinium]

Could you check if adding

        "-fdebug-prefix-map={project_source_dir}=.",
        "-fdebug-prefix-map={gccpath}=.",

to here would fix it?

[WasabiFan]

I don't see a change to the metadata if I add those. As far as I can tell they are implied by the existing ones. If I remove the -ffile-prefix-map args entirely, absolute paths are populated in the executable and tools are able to resolve them (no resolution necessary).