LLVM Bugzilla is read-only and represents the historical archive of all LLVM issues filled before November 26, 2021. Use github to submit LLVM bugs

Bug 42401 - Corrupt debug info when using lld with gcc 9.1
Summary: Corrupt debug info when using lld with gcc 9.1
Status: RESOLVED DUPLICATE of bug 40482
Alias: None
Product: lld
Classification: Unclassified
Component: ELF (show other bugs)
Version: unspecified
Hardware: PC Linux
: P enhancement
Assignee: Unassigned LLVM Bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-06-26 00:49 PDT by Moritz Sichert
Modified: 2019-06-28 05:21 PDT (History)
5 users (show)

See Also:
Fixed By Commit(s):


Attachments
foo.c assembled with clang (5.08 KB, text/plain)
2019-06-28 02:34 PDT, Moritz Sichert
Details
foo.c assembled with gcc (2.00 KB, text/plain)
2019-06-28 02:34 PDT, Moritz Sichert
Details
main.c assembled with clang (5.10 KB, text/plain)
2019-06-28 02:35 PDT, Moritz Sichert
Details
main.c assembled with gcc (2.03 KB, text/plain)
2019-06-28 02:35 PDT, Moritz Sichert
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Moritz Sichert 2019-06-26 00:49:03 PDT
I have the following program:

foo.cpp:

int foo() {
    return 1;
}


main.cpp:

int main() {
    return 0;
}



If I compile it with gcc 9.1 like this:

gcc -g -fuse-ld=lld -o main foo.cpp main.cpp

I get corrupted debug info. gdb says:

Reading symbols from main...
Dwarf Error: wrong version in compilation unit header (is 1024, should be 2, 3, 4 or 5) [in module <...>/main]
(No debugging symbols found in main)


This is the output of "readelf --debug-dump=info main":

Contents of the .debug_info section:

  Compilation Unit @ offset 0x0:
   Length:        0x53 (32-bit)
   Version:       4
   Abbrev Offset: 0x0
   Pointer Size:  8
 <0><b>: Abbrev Number: 1 (DW_TAG_compile_unit)
    <c>   DW_AT_producer    : (indirect string, offset: 0x31): GNU C++14 9.1.0 -mtune=generic -march=x86-64 -g -fuse-ld=lld
    <10>   DW_AT_language    : 4	(C++)
    <11>   DW_AT_name        : (indirect string, offset: 0x6e): foo.cpp
    <15>   DW_AT_comp_dir    : (indirect string, offset: 0x0): <...>
    <19>   DW_AT_low_pc      : 0x10f9
    <21>   DW_AT_high_pc     : 0xb
    <29>   DW_AT_stmt_list   : 0x0
 <1><2d>: Abbrev Number: 2 (DW_TAG_subprogram)
    <2e>   DW_AT_external    : 1
    <2e>   DW_AT_name        : foo
    <32>   DW_AT_decl_file   : 1
    <33>   DW_AT_decl_line   : 1
    <34>   DW_AT_decl_column : 5
    <35>   DW_AT_linkage_name: (indirect string, offset: 0x24): _Z3foov
    <39>   DW_AT_type        : <0x4f>
    <3d>   DW_AT_low_pc      : 0x10f9
    <45>   DW_AT_high_pc     : 0xb
    <4d>   DW_AT_frame_base  : 1 byte block: 9c 	(DW_OP_call_frame_cfa)
    <4f>   DW_AT_GNU_all_call_sites: 1
 <1><4f>: Abbrev Number: 3 (DW_TAG_base_type)
    <50>   DW_AT_byte_size   : 4
    <51>   DW_AT_encoding    : 5	(signed)
    <52>   DW_AT_name        : int
 <1><56>: Abbrev Number: 0
readelf: Warning: Invalid pointer size (59) in compunit header, using 4 instead
  Compilation Unit @ offset 0x57:
   Length:        0x4f00 (32-bit)
   Version:       1024
   Abbrev Offset: 0x8000000
   Pointer Size:  4
readelf: Warning: Debug info is corrupted, .debug_info header at 0x57 has length 4f00



This problem does not occur when using ld or gold. Also, it doesn't happen when using gcc < 9.1 or clang.
Comment 1 David Blaikie 2019-06-26 08:32:01 PDT
Might be helpful to attach assembly for the file(s) (if, using that assembly, this can be reproduced without gcc - eg: does assembling and linking them with clang still produce the failure?)
Comment 2 Fangrui Song 2019-06-27 23:09:02 PDT
I cannot reproduce the gdb issue with core/gcc 9.1.0-2 on Arch Linux.

As David suggested, it would be good to have gcc -g -S output.

You may also use -Wl,--reproduce=/tmp/rep.tar to get a reproduce tarball with all input files.

Also, make sure you are using a sufficiently newer lld: 8.0 or trunk. 7.0 may have some bugs that have been fixed.

gcc -g -fuse-ld=lld uses the ld.lld found in PATH. If you have a locally built lld, that command may not use it. (Tip: append '-###' to check which linker gcc uses)
Comment 3 Moritz Sichert 2019-06-28 02:33:51 PDT
I'm also using 9.1.0-2 on Arch Linux:

$ gcc --version
gcc (GCC) 9.1.0

$ clang --version
clang version 8.0.0 (tags/RELEASE_800/final)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin

$ ld.lld --version
LLD 8.0.0 (compatible with GNU linkers)


When I assemble the files with clang but link them with gcc, the bug does not happen. I attached the assembly for both files generated by gcc and by clang.
Comment 4 Moritz Sichert 2019-06-28 02:34:32 PDT
Created attachment 22156 [details]
foo.c assembled with clang
Comment 5 Moritz Sichert 2019-06-28 02:34:57 PDT
Created attachment 22157 [details]
foo.c assembled with gcc
Comment 6 Moritz Sichert 2019-06-28 02:35:11 PDT
Created attachment 22158 [details]
main.c assembled with clang
Comment 7 Moritz Sichert 2019-06-28 02:35:31 PDT
Created attachment 22159 [details]
main.c assembled with gcc
Comment 8 Fangrui Song 2019-06-28 04:14:45 PDT
clang -fuse-ld=lld foo-gcc.s foo-main.s -o main
gdb main

I reproduced the

  Reading symbols from a.arch...Dwarf Error: wrong version in compilation unit header (is 1024, should be 2, 3, 4 or 5) [in module /tmp/rep/a.arch]

bug with Arch Linux extra/lld 8.0.0-1 and the prebuilt 8.0.0 Ubuntu 18.04 archive on http://releases.llvm.org/download.html#8.0.0

lld trunk is fine. I checked out the 8.x branch https://github.com/llvm/llvm-project/tree/release/8.x, it is also fine.

So this is a bug (I cannot narrow down to the revision that fixed the issue) in the 8.0.0 release that will not go into the 8.0.1 release.

Moritz, you may just wait for the 8.0.1 release :)
Comment 9 Moritz Sichert 2019-06-28 05:21:16 PDT
Thanks for the hint! I found this was fixed in Bug 40482

*** This bug has been marked as a duplicate of bug 40482 ***