large debug info can not recognized

[SquallATF]

I compiled a debug version of clang, but bouth lldb and gdb can not show debug info.
llvm-objdump.exe -h clang.exe output

Sections:
Idx Name           Size     VMA              Type
  0 .text          07c657a6 0000000140001000 TEXT
  1 .rdata         0171a77c 0000000147c67000 DATA
  2 .buildid       00000035 0000000149382000 DATA
  3 .data          00015800 0000000149383000 DATA
  4 .pdata         009c0c90 00000001493f1000 DATA
  5 .tls           00000038 0000000149db2000 DATA
  6 .reloc         000a6ab8 0000000149db3000 DATA
  7 .debug_abbrev  00455be8 0000000149e5a000 DATA, DEBUG
  8 .debug_aranges 000001e0 000000014a2b0000 DATA, DEBUG
  9 .debug_info    19601934 000000014a2b1000 DATA, DEBUG
 10 .debug_line    07d4914f 00000001638b3000 DATA, DEBUG
 11 .debug_loc     00380b05 000000016b5fd000 DATA, DEBUG
 12 .debug_ranges  027a99d0 000000016b97e000 DATA, DEBUG
 13 .debug_str     3038e842 000000016e128000 DATA, DEBUG

use llvm-objcopy --only-keep-debug export the debug info, and the debug info size is about 1.43GB.

load clang.exe use gdb show No debugging symbols found in clang.exe
load clang.exe use lldb and run to breakpoint, and run source info show error: No debug info for the selected frame.

[mstorsjo]

@alvinhochun Does this sound like something you've run into?

[alvinhochun]

Nothing I am aware of. In my lldb build the debug info of liblldb.dll gets as big as 1.8GB, and both gdb and lldb is able to load this debug info with split debug file linked using gnu-debuglink (requires recent lldb built off main or with backported patches). However, if I don't split the debug info Windows refuses to load the DLL at all (0xc000007b STATUS_INVALID_IMAGE_FORMAT). I would suggest trying gnu-debuglink and see if it works:

llvm-objcopy --only-keep-debug clang.exe clang.exe.debug
llvm-strip --strip-debug clang.exe
llvm-objcopy --add-gnu-debuglink=clang.exe.debug clang.exe

[SquallATF]

gnu-debuglink not work for me. The result is the same as before. llvm version is llvm/llvm-project@5d7b1a5 , debug build use CMAKE_BUILD_TYPE=Debug
The result output of llvm-dwarfdump -v -n main clang.exe looks ok

0x00001145: DW_TAG_GNU_call_site
              DW_AT_abstract_origin     (0x00001241 "main")
              DW_AT_low_pc      (0x00000001400013d6)

0x00001241: DW_TAG_subprogram
              DW_AT_name        ("main")
              DW_AT_decl_file   ("E:/Source/git/mingw-w64/mingw-w64-crt/build15/../include/internal.h")
              DW_AT_decl_line   (116)
              DW_AT_prototyped  (true)
              DW_AT_type        (0x0000007b "int")
              DW_AT_declaration (true)
              DW_AT_external    (true)

0x000ae8de: DW_TAG_subprogram
              DW_AT_low_pc      (0x000000014002f130)
              DW_AT_high_pc     (0x000000014002f16e)
              DW_AT_frame_base  (DW_OP_reg6 RBP)
              DW_AT_name        ("main")
              DW_AT_decl_file   ("K:/llvm15build/build-stage1/tools/clang/tools/driver/clang-driver.cpp")
              DW_AT_decl_line   (11)
              DW_AT_type        (0x000ae914 "int")
              DW_AT_external    (true)

[alvinhochun]

Does smaller binaries like llvm-objcopy or llvm-readobj, which should have smaller debug info, also suffer from the same issue for you?

I build RelWithDebInfo and I use the 20220323 build of llvm-mingw to cross compile llvm/lldb from Linux. Are you using your own llvm build from trunk and compiling natively on Windows?

[SquallATF]

I build RelWithDebInfo and I use the 20220323 build of llvm-mingw to cross compile llvm/lldb from Linux. Are you using your own llvm build from trunk and compiling natively on Windows?

Yes I build from main under windows. There is no problem in debugging llvm-readobj, and the source code can be displayed normally.

But debugging clang can not display the source code.

[alvinhochun]

Can you try inspecting the clang.exe with llvm-dwarfdump -v? Perhaps also try addr2line from a mingw-builds release?

[SquallATF]

I tested lldb from llvm-mingw-20220323-ucrt-x86_64.zip and same result.
llvm-dwarfdump -v -n main clang.exe output

clang.exe:      file format COFF-x86-64

0x00001145: DW_TAG_GNU_call_site [46]   (0x00000fcc)
              DW_AT_abstract_origin [DW_FORM_ref4]      (cu + 0x1242 => {0x00001242} "main")
              DW_AT_low_pc [DW_FORM_addr]       (0x00000001400013d6)

0x00001242: DW_TAG_subprogram [63] * (0x0000000b)
              DW_AT_name [DW_FORM_strp] ( .debug_str[0x00000bf9] = "main")
              DW_AT_decl_file [DW_FORM_data1]   ("E:/Source/git/mingw-w64/mingw-w64-crt/build15/../include/internal.h")
              DW_AT_decl_line [DW_FORM_data1]   (116)
              DW_AT_prototyped [DW_FORM_flag_present]   (true)
              DW_AT_type [DW_FORM_ref4] (cu + 0x007b => {0x0000007b} "int")
              DW_AT_declaration [DW_FORM_flag_present]  (true)
              DW_AT_external [DW_FORM_flag_present]     (true)

0x000af523: DW_TAG_subprogram [2] * (0x000af504)
              DW_AT_low_pc [DW_FORM_addr]       (0x000000014002f530)
              DW_AT_high_pc [DW_FORM_data4]     (0x0000003e)
              DW_AT_frame_base [DW_FORM_exprloc]        (DW_OP_reg6 RBP)
              DW_AT_name [DW_FORM_strp] ( .debug_str[0x0014d6cc] = "main")
              DW_AT_decl_file [DW_FORM_data1]   ("K:/llvm15build/build-stage1/tools/clang/tools/driver/clang-driver.cpp")
              DW_AT_decl_line [DW_FORM_data1]   (11)
              DW_AT_type [DW_FORM_ref4] (cu + 0x0060 => {0x000af559} "int")
              DW_AT_external [DW_FORM_flag_present]     (true)

addr2line.exe -f -p -e clang.exe 0x000000014002f530 output

main at K:/llvm15build/build-stage1/tools/clang/tools/driver/clang-driver.cpp:11

[SquallATF]

I have rebuild debug clang use clang from llvm-mingw-20220323-ucrt-x86_64.zip, and debug info can be loaded normally. so this issue is in the main branch

[mstorsjo]

I managed to bisect this issue down to the commit that caused it, which is llvm/llvm-project@9ffeaaa.

Normally, for section names that don't fit in the 8 byte field, they're written as /<decimaloffset>. If this doesn't fit in 8 bytes, it's written as //<base64offset>. Previously, all such section names were at the start of the string table and had small offsets, but after this, they can appear anywhere in the table - so some sections get a base64 offset. But I guess that neither lldb nor gdb expect to see and decode base64 offsets for section names in executables/DLLs.

So I guess the fix here would be to make sure that the section names don't get optimized but just stuck at the start of the string table, while letting the optimizer work on all the strings for symbols. (Or just maybe revert the whole change as it probably doesn't add all that much value in the end?)