[lldb] lldb not reading compile units for binaries compiled with -gdwarf64

[aallrd]

I expect lldb to be able to display source lines in backtraces and print the program sources.
It does not seem to work for binaries compiled with the -gdwarf64 flag.
clang: 20.1.2
lldb: 20.1.2

Reproduction environment setup

$ docker run --rm -it fedora:43
$ cat /etc/redhat-release
Fedora release 43 (Rawhide)
$ uname -a
Linux 63ba7c3804df 6.8.0-56-generic #58-Ubuntu SMP PREEMPT_DYNAMIC Fri Feb 14 15:19:53 UTC 2025 aarch64 GNU/Linux
$ dnf install -y lldb clang
$ clang++ --version
clang version 20.1.2 (Fedora 20.1.2-3.fc43)
Target: aarch64-redhat-linux-gnu
Thread model: posix
InstalledDir: /usr/lib64/llvm20/bin
Configuration file: /etc/clang/aarch64-redhat-linux-gnu-clang++.cfg
$ lldb --version
lldb version 20.1.2
$ cat <<EOF > main.cpp
#include <iostream>

int main()
{
  std::cout << "Hello World!" << std::endl;
  return 0;
}
EOF

The normal behavior:

$ clang++ -g main.cpp -o main
$ lldb --batch -O "settings set target.disable-aslr false" -o "breakpoint set --name main" -o "run" main
(lldb) settings set target.disable-aslr false
(lldb) target create "main"
Current executable set to '/main' (aarch64).
(lldb) breakpoint set --name main
Breakpoint 1: where = main`main + 24 at main.cpp:5:13, address = 0x00000000004008c4
(lldb) run
Process 107 launched: '/main' (aarch64)
Process 107 stopped
* thread #1, name = 'main', stop reason = breakpoint 1.1
    frame #0: 0x00000000004008c4 main`main at main.cpp:5:13
   2
   3    int main()
   4    {
-> 5      std::cout << "Hello World!" << std::endl;
   6      return 0;
   7    }

When compiled with -gdwarf64, the sources are not printed anymore:

$ clang++ -g -gdwarf64 main.cpp -o main
$ lldb --batch -O "settings set target.disable-aslr false" -o "breakpoint set --name main" -o "run" main
(lldb) settings set target.disable-aslr false
(lldb) target create "main"
Current executable set to '/main' (aarch64).
(lldb) breakpoint set --name main
Breakpoint 1: where = main`main, address = 0x00000000004008ac
(lldb) run
Process 125 launched: '/main' (aarch64)
Process 125 stopped
* thread #1, name = 'main', stop reason = breakpoint 1.1
    frame #0: 0x00000000004008ac main`main
main`main:
->  0x4008ac <+0>:  sub    sp, sp, #0x20
    0x4008b0 <+4>:  stp    x29, x30, [sp, #0x10]
    0x4008b4 <+8>:  add    x29, sp, #0x10
    0x4008b8 <+12>: mov    w8, wzr

Without -gdwarf64, the compile units are read successfully:

$ lldb main
$ (lldb) target create "main"
Current executable set to '/main' (aarch64).
$ (lldb) script lldb.target.module['main'].GetNumCompileUnits()
1
$ (lldb) script
Python Interactive Interpreter. To exit, type 'quit()', 'exit()' or Ctrl-D.
>>> m = lldb.target.module['main']
>>> for i in range(m.GetNumCompileUnits()):
...     print(m.GetCompileUnitAtIndex(i))
...
0xb76c45e67390: CompileUnit{0x00000000}, language = "c++14", file = '/main.cpp'

With -gdwarf64, the compile units are not read successfully ?

$ lldb main
$ (lldb) target create "main"
Current executable set to '/main' (aarch64).
$ (lldb) script lldb.target.module['main'].GetNumCompileUnits()
1
$ (lldb) script
Python Interactive Interpreter. To exit, type 'quit()', 'exit()' or Ctrl-D.
>>> m = lldb.target.module['main']
>>> for i in range(m.GetNumCompileUnits()):
...     print(m.GetCompileUnitAtIndex(i))
...
0xbf8930d7abf0: CompileUnit{0x00000000}, language = "<not loaded>", file = ''

[llvmbot]

@llvm/issue-subscribers-debuginfo

Author: Antoine Allard (aallrd)

I expect `lldb` to be able to display source lines in backtraces and print the program sources. It does not seem to work for binaries compiled with the `-gdwarf64` flag. **_clang_**: 20.1.2 **_lldb_**: 20.1.2

Reproduction environment setup

$ docker run --rm -it fedora:43
$ cat /etc/redhat-release
Fedora release 43 (Rawhide)
$ uname -a
Linux 63ba7c3804df 6.8.0-56-generic #<!-- -->58-Ubuntu SMP PREEMPT_DYNAMIC Fri Feb 14 15:19:53 UTC 2025 aarch64 GNU/Linux
$ dnf install -y lldb clang
$ clang++ --version
clang version 20.1.2 (Fedora 20.1.2-3.fc43)
Target: aarch64-redhat-linux-gnu
Thread model: posix
InstalledDir: /usr/lib64/llvm20/bin
Configuration file: /etc/clang/aarch64-redhat-linux-gnu-clang++.cfg
$ lldb --version
lldb version 20.1.2
$ cat &lt;&lt;EOF &gt; main.cpp
#include &lt;iostream&gt;

int main()
{
  std::cout &lt;&lt; "Hello World!" &lt;&lt; std::endl;
  return 0;
}
EOF

The normal behavior:

$ clang++ -g main.cpp -o main
$ lldb --batch -O "settings set target.disable-aslr false" -o "breakpoint set --name main" -o "run" main
(lldb) settings set target.disable-aslr false
(lldb) target create "main"
Current executable set to '/main' (aarch64).
(lldb) breakpoint set --name main
Breakpoint 1: where = main`main + 24 at main.cpp:5:13, address = 0x00000000004008c4
(lldb) run
Process 107 launched: '/main' (aarch64)
Process 107 stopped
* thread #<!-- -->1, name = 'main', stop reason = breakpoint 1.1
    frame #<!-- -->0: 0x00000000004008c4 main`main at main.cpp:5:13
   2
   3    int main()
   4    {
-&gt; 5      std::cout &lt;&lt; "Hello World!" &lt;&lt; std::endl;
   6      return 0;
   7    }

When compiled with -gdwarf64, the sources are not printed anymore:

$ clang++ -g -gdwarf64 main.cpp -o main
$ lldb --batch -O "settings set target.disable-aslr false" -o "breakpoint set --name main" -o "run" main
(lldb) settings set target.disable-aslr false
(lldb) target create "main"
Current executable set to '/main' (aarch64).
(lldb) breakpoint set --name main
Breakpoint 1: where = main`main, address = 0x00000000004008ac
(lldb) run
Process 125 launched: '/main' (aarch64)
Process 125 stopped
* thread #<!-- -->1, name = 'main', stop reason = breakpoint 1.1
    frame #<!-- -->0: 0x00000000004008ac main`main
main`main:
-&gt;  0x4008ac &lt;+0&gt;:  sub    sp, sp, #<!-- -->0x20
    0x4008b0 &lt;+4&gt;:  stp    x29, x30, [sp, #<!-- -->0x10]
    0x4008b4 &lt;+8&gt;:  add    x29, sp, #<!-- -->0x10
    0x4008b8 &lt;+12&gt;: mov    w8, wzr

Without -gdwarf64, the compile units are read successfully:

$ lldb main
$ (lldb) target create "main"
Current executable set to '/main' (aarch64).
$ (lldb) script lldb.target.module['main'].GetNumCompileUnits()
1
$ (lldb) script
Python Interactive Interpreter. To exit, type 'quit()', 'exit()' or Ctrl-D.
>>> m = lldb.target.module['main']
>>> for i in range(m.GetNumCompileUnits()):
...     print(m.GetCompileUnitAtIndex(i))
...
0xb76c45e67390: CompileUnit{0x00000000}, language = "c++14", file = '/main.cpp'

With -gdwarf64, the compile units are not read successfully ?

$ lldb main
$ (lldb) target create "main"
Current executable set to '/main' (aarch64).
$ (lldb) script lldb.target.module['main'].GetNumCompileUnits()
1
$ (lldb) script
Python Interactive Interpreter. To exit, type 'quit()', 'exit()' or Ctrl-D.
>>> m = lldb.target.module['main']
>>> for i in range(m.GetNumCompileUnits()):
...     print(m.GetCompileUnitAtIndex(i))
...
0xbf8930d7abf0: CompileUnit{0x00000000}, language = "<not loaded>", file = ''

[llvmbot]

@llvm/issue-subscribers-lldb

Author: Antoine Allard (aallrd)

I expect `lldb` to be able to display source lines in backtraces and print the program sources. It does not seem to work for binaries compiled with the `-gdwarf64` flag. **_clang_**: 20.1.2 **_lldb_**: 20.1.2

Reproduction environment setup

$ docker run --rm -it fedora:43
$ cat /etc/redhat-release
Fedora release 43 (Rawhide)
$ uname -a
Linux 63ba7c3804df 6.8.0-56-generic #<!-- -->58-Ubuntu SMP PREEMPT_DYNAMIC Fri Feb 14 15:19:53 UTC 2025 aarch64 GNU/Linux
$ dnf install -y lldb clang
$ clang++ --version
clang version 20.1.2 (Fedora 20.1.2-3.fc43)
Target: aarch64-redhat-linux-gnu
Thread model: posix
InstalledDir: /usr/lib64/llvm20/bin
Configuration file: /etc/clang/aarch64-redhat-linux-gnu-clang++.cfg
$ lldb --version
lldb version 20.1.2
$ cat &lt;&lt;EOF &gt; main.cpp
#include &lt;iostream&gt;

int main()
{
  std::cout &lt;&lt; "Hello World!" &lt;&lt; std::endl;
  return 0;
}
EOF

The normal behavior:

$ clang++ -g main.cpp -o main
$ lldb --batch -O "settings set target.disable-aslr false" -o "breakpoint set --name main" -o "run" main
(lldb) settings set target.disable-aslr false
(lldb) target create "main"
Current executable set to '/main' (aarch64).
(lldb) breakpoint set --name main
Breakpoint 1: where = main`main + 24 at main.cpp:5:13, address = 0x00000000004008c4
(lldb) run
Process 107 launched: '/main' (aarch64)
Process 107 stopped
* thread #<!-- -->1, name = 'main', stop reason = breakpoint 1.1
    frame #<!-- -->0: 0x00000000004008c4 main`main at main.cpp:5:13
   2
   3    int main()
   4    {
-&gt; 5      std::cout &lt;&lt; "Hello World!" &lt;&lt; std::endl;
   6      return 0;
   7    }

When compiled with -gdwarf64, the sources are not printed anymore:

$ clang++ -g -gdwarf64 main.cpp -o main
$ lldb --batch -O "settings set target.disable-aslr false" -o "breakpoint set --name main" -o "run" main
(lldb) settings set target.disable-aslr false
(lldb) target create "main"
Current executable set to '/main' (aarch64).
(lldb) breakpoint set --name main
Breakpoint 1: where = main`main, address = 0x00000000004008ac
(lldb) run
Process 125 launched: '/main' (aarch64)
Process 125 stopped
* thread #<!-- -->1, name = 'main', stop reason = breakpoint 1.1
    frame #<!-- -->0: 0x00000000004008ac main`main
main`main:
-&gt;  0x4008ac &lt;+0&gt;:  sub    sp, sp, #<!-- -->0x20
    0x4008b0 &lt;+4&gt;:  stp    x29, x30, [sp, #<!-- -->0x10]
    0x4008b4 &lt;+8&gt;:  add    x29, sp, #<!-- -->0x10
    0x4008b8 &lt;+12&gt;: mov    w8, wzr

Without -gdwarf64, the compile units are read successfully:

$ lldb main
$ (lldb) target create "main"
Current executable set to '/main' (aarch64).
$ (lldb) script lldb.target.module['main'].GetNumCompileUnits()
1
$ (lldb) script
Python Interactive Interpreter. To exit, type 'quit()', 'exit()' or Ctrl-D.
>>> m = lldb.target.module['main']
>>> for i in range(m.GetNumCompileUnits()):
...     print(m.GetCompileUnitAtIndex(i))
...
0xb76c45e67390: CompileUnit{0x00000000}, language = "c++14", file = '/main.cpp'

With -gdwarf64, the compile units are not read successfully ?

$ lldb main
$ (lldb) target create "main"
Current executable set to '/main' (aarch64).
$ (lldb) script lldb.target.module['main'].GetNumCompileUnits()
1
$ (lldb) script
Python Interactive Interpreter. To exit, type 'quit()', 'exit()' or Ctrl-D.
>>> m = lldb.target.module['main']
>>> for i in range(m.GetNumCompileUnits()):
...     print(m.GetCompileUnitAtIndex(i))
...
0xbf8930d7abf0: CompileUnit{0x00000000}, language = "<not loaded>", file = ''

[aallrd]

Confirming the issue does not come from the compiler since it works with GDB:

$ gdb --version
GNU gdb (Fedora Linux) 16.2-3.fc43
Copyright (C) 2024 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
$ clang++ -g -gdwarf64 main.cpp -o main
$ gdb --batch -ex "break main" -ex "run" -ex "bt" -ex "list" main
Breakpoint 1 at 0x4008c4: file main.cpp, line 5.
warning: Error disabling address space randomization: Operation not permitted
Function(s) ^std::(move|forward|as_const|(__)?addressof) will be skipped when stepping.
Function(s) ^std::(shared|unique)_ptr<.*>::(get|operator) will be skipped when stepping.
Function(s) ^std::(basic_string|vector|array|deque|(forward_)?list|(unordered_|flat_)?(multi)?(map|set)|span)<.*>::(c?r?(begin|end)|front|back|data|size|empty) will be skipped when stepping.
Function(s) ^std::(basic_string|vector|array|deque|span)<.*>::operator.] will be skipped when stepping.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Breakpoint 1, main () at main.cpp:5
5         std::cout << "Hello World!" << std::endl;
#0  main () at main.cpp:5
1       #include <iostream>
2
3       int main()
4       {
5         std::cout << "Hello World!" << std::endl;
6         return 0;
7       }

[hapeeeeee]

In LLDB, there is almost no content related to DWARF64. I only found a small reference here:

llvm-project/lldb/source/Plugins/SymbolFile/DWARF/DWARFFormValue.cpp

Lines 425 to 428 in c6cec7b

	DumpAddress(s.AsRawOstream(), uvalue,
	4 * 2); // 4 for DWARF32, 8 for DWARF64, but we don't
	// support DWARF64 yet
	break;

This seems to suggest that LLDB currently does not support DWARF64.