Description of problem: Build failed with this $summary. Version-Release number of selected component (if applicable): dwz-0.12-5.fc27.x86_64 assumed How reproducible: Always. Steps to Reproduce: Build LLVM+LLDB (with system GCC) and run DWZ on it: https://git.jankratochvil.net/?p=lldb-experimental.git;a=tree;hb=8701d40e3b3ee0cdf671e9f49090b5615dae8788 Actual results: https://copr-be.cloud.fedoraproject.org/results/jankratochvil/lldb/fedora-27-x86_64/00737951-lldb-experimental/build.log BUILDSTDERR: dwz: ./opt/lldb-experimental/lib64/liblldb.so.7.0.0-7.0.0-0.20180406snap0.fc27.x86_64.debug: Couldn't find DIE referenced by DW_OP_GNU_parameter_ref Expected results: Built package. Additional info: I had to disable DWZ there: %global _find_debuginfo_dwz_opts %{nil} It took too many hours to process the package anyway. I did not check other releases of Fedora for reproducibility. I did not investigate if it is GCC's fault or DWZ's fault.
Yes, it was: dwz-0.12-5.fc27.x86_64
Is the liblldb.so.7.0.0-7.0.0-0.20180406snap0.fc27.x86_64.debug that caused the issue available somewhere for inspection?
https://people.redhat.com/jkratoch/lldb-server-7.0.0-0.20180408snap0.fc27.x86_64.debug.xz dwz: ./opt/lldb-experimental/bin/lldb-server-7.0.0-0.20180408snap0.fc27.x86_64.debug: Couldn't find DIE referenced by DW_OP_GNU_parameter_ref
Wow, that is a fairly big debug file. The problem (found with the elfutils tests/varlocs which checks all location descriptions of arguments and variables) seems to be the location description [b20592] of the base parameter [295bbd4] of the GetEscapedChild function [295bbad] in the ClangASTImporter.cpp compile unit [2877133]: debug_info: [...] [2877133] compile_unit abbrev: 456 producer (strp) "GNU C++11 7.3.1 20180303 (Red Hat 7.3.1- 5) -m64 -mtune=generic -march=x86-64 -g -g -O2 -O2 -std=c++11 -fstack-protector- strong -fasynchronous-unwind-tables -fPIC -fvisibility-inlines-hidden -ffunction -sections -fdata-sections -fno-exceptions -fno-rtti --param ssp-buffer-size=4" language (data1) C_plus_plus (4) name (strp) "/usr/src/debug/lldb-experimental-7.0.0-0 .20180408snap0.fc27.x86_64/tools/lldb/source/Symbol/ClangASTImporter.cpp" comp_dir (strp) "/usr/src/debug/lldb-experimental-7.0.0-0 .20180408snap0.fc27.x86_64/build-release/tools/lldb/source/Symbol" ranges (sec_offset) range list [370c80] low_pc (addr) +000000000000000000 stmt_list (sec_offset) 1999513 [...] [295bbad] subprogram abbrev: 317 abstract_origin (ref_udata) [2957914] low_pc (addr) +000000000000000000 high_pc (udata) 554 (+0x000000000000022a) frame_base (exprloc) [ 0] call_frame_cfa object_pointer (ref_udata) [295bbc4] GNU_all_call_sites (flag_present) yes sibling (ref_udata) [295ca87] [295bbc4] formal_parameter abbrev: 9 abstract_origin (ref_udata) [2957922] location (sec_offset) location list [b204d1] [295bbcc] formal_parameter abbrev: 9 abstract_origin (ref_udata) [295792a] location (sec_offset) location list [b20546] [295bbd4] formal_parameter abbrev: 9 abstract_origin (ref_udata) [2957934] location (sec_offset) location list [b20592] [295bbdc] lexical_block abbrev: 134 abstract_origin (ref_udata) [295793e] ranges (sec_offset) range list [35ef70] [...] debug_loc: [...] CU [2877133] base: +000000000000000000 [...] [b20592] range 0, 49 +000000000000000000.. +0x0000000000000048 [ 0] GNU_parameter_ref [edc1118] [ 5] stack_value range 6a, 20b +0x000000000000006a.. +0x000000000000020a [ 0] lit0 [ 1] stack_value So that [edc1118] should be a CU relative reference to the DW_TAG_formal_parameter DIE. But [2877133] + [edc1118] = [1163824b] seems a little too big.
Just in case it helps here are some other DIEs referenced. This is the subprogram DIE that is the abstract_origin: [2957914] subprogram abbrev: 27 specification (ref_udata) [292dba6] object_pointer (ref_udata) [2957922] inline (data1) declared_inlined (3) object_pointer (ref_udata) [2957922] sibling (ref_udata) [2957984] [2957922] formal_parameter abbrev: 18 name (strp) "this" type (ref_udata) [292dd51] artificial (flag_present) yes [295792a] formal_parameter abbrev: 112 name (strp) "decl" decl_file (data1) ClangASTImporter.cpp (6) decl_line (data1) 165 type (ref_udata) [2922f78] [2957934] formal_parameter abbrev: 112 name (strp) "base" decl_file (data1) ClangASTImporter.cpp (6) decl_line (data1) 166 type (ref_udata) [292328f] And the specification of that one: [292dba6] subprogram abbrev: 64 external (flag_present) yes name (strp) "GetEscapedChild" decl_file (data1) ClangASTImporter.cpp (6) decl_line (data1) 165 linkage_name (strp) "_ZN19DeclContextOverride15GetEscaped ChildEPN5clang4DeclEPNS0_11DeclContextE" type (ref_udata) [2922f78] declaration (flag_present) yes object_pointer (ref_udata) [292dbba] sibling (ref_udata) [292dbc7] [292dbba] formal_parameter abbrev: 1 type (ref_udata) [292dd4c] artificial (flag_present) yes [292dbbe] formal_parameter abbrev: 2 type (ref_udata) [2922f78] [292dbc2] formal_parameter abbrev: 2 type (ref_udata) [292328f]
BTW. I assumed the lldb-server-7.0.0-0.20180408snap0.fc27.x86_64.debug was what was generated by GCC and processed by dwz. But seeing that it already contains partial_units I assume it is the result of dwz processing that file. Jan, is that file what you got before or after dwz processing? Does the error occur on the file as uploaded or is it the result of (partial) dwz processing?
I have run the build and it stopped on the DWZ error so I took the file and sent it to you. I assumed it was not processed by DWZ yet but I do not know. I will build it again with DWZ disabled and send you that one.
I have tried to build it without DWZ but then the bug was not reproducible. You should try to reproduce it yourself, just use: git clone git://git.jankratochvil.net/lldb-experimental and delete there the line: %global _find_debuginfo_dwz_opts %{nil} I get the error on F-27 x86_64 again: extracting debug info from /home/jkratoch/redhat/lldb-experimental/BUILDROOT/lldb-experimental-7.0.0-0.20180408snap0.fc27.x86_64/opt/lldb-experimental/lib64/python2.7/site-packages/readline.so dwz: ./opt/lldb-experimental/bin/lldb-server-7.0.0-0.20180408snap0.fc27.x86_64.debug: Couldn't find DIE referenced by DW_OP_GNU_parameter_ref dwz: ./opt/lldb-experimental/bin/lldb-test-7.0.0-0.20180408snap0.fc27.x86_64.debug: Couldn't find DIE referenced by DW_OP_GNU_parameter_ref
(In reply to Jan Kratochvil from comment #8) > I have tried to build it without DWZ but then the bug was not reproducible. Do you mean that after the build running dwz -h -r -m multi.dwz ... .debug files ... succeeds without error? Did you use any (other) options to dwz? > I get the error on F-27 x86_64 again: > extracting debug info from > /home/jkratoch/redhat/lldb-experimental/BUILDROOT/lldb-experimental-7.0.0-0. > 20180408snap0.fc27.x86_64/opt/lldb-experimental/lib64/python2.7/site- > packages/readline.so > dwz: > ./opt/lldb-experimental/bin/lldb-server-7.0.0-0.20180408snap0.fc27.x86_64. > debug: Couldn't find DIE referenced by DW_OP_GNU_parameter_ref > dwz: > ./opt/lldb-experimental/bin/lldb-test-7.0.0-0.20180408snap0.fc27.x86_64. > debug: Couldn't find DIE referenced by DW_OP_GNU_parameter_ref It is a pity the find-debuginfo.sh script doesn't seem to print how exactly dwz is invoked.
(In reply to Mark Wielaard from comment #9) > (In reply to Jan Kratochvil from comment #8) > > I have tried to build it without DWZ but then the bug was not reproducible. > > Do you mean that after the build running dwz -h -r -m multi.dwz ... .debug > files ... succeeds without error? Did you use any (other) options to dwz? I just ran this command and it did succeed: dwz -l 10000000 -L 110000000 ./BUILDROOT/lldb-experimental-7.0.0-0.20180408snap0.fc27.x86_64/usr/lib/debug/opt/lldb-experimental/bin/lldb-server-7.0.0-0.20180408snap0.fc27.x86_64.debug I sure could troubleshoot it more but you can do the same.
I see the same issue for some package in openSUSE. There's one example of a shared library: https://w3.scz.suse.com/~mliska/tmp/libqtscript_gui.so.1.0.0 For which dwz breaks debug info: $ cp libqtscript_gui.so.1.0.0 x && dwz x && dwz x dwz: x: Couldn't find DIE referenced by DW_OP_GNU_parameter_ref
(In reply to Martin Liška from comment #11) > https://w3.scz.suse.com/~mliska/tmp/libqtscript_gui.so.1.0.0 Host w3.scz.suse.com not found: 3(NXDOMAIN)
Sorry, please use this link: https://doc-0s-4c-docs.googleusercontent.com/docs/securesc/ha0ro937gcuc7l7deffksulhg5h7mbp1/lgqqkkd950cdhik42a6id491k2gv8q95/1534852800000/02812589201684103265/*/10000IeuSYD8TsEIVDDYlRAJDCwwPHyTI?e=download
So I have one example where one can theoretically debug the issue: File: https://drive.google.com/file/d/19XG_rfaU9IHadpM0jwf4GSOhP0kE3Xb8/view?usp=sharing Using following patch: diff --git a/dwz.c b/dwz.c index d348418..81c5ed4 100644 --- a/dwz.c +++ b/dwz.c @@ -1486,8 +1486,8 @@ read_exprloc (DSO *dso, dw_die_ref die, unsigned char *ptr, size_t len, ref = off_htab_lookup (cu, cu->cu_offset + addr); if (ref == NULL) { - error (0, 0, "%s: Couldn't find DIE referenced by %s", - dso->filename, get_DW_OP_str (op)); + error (0, 0, "%s: Couldn't find DIE referenced by %s, offset: %ld", + dso->filename, get_DW_OP_str (op), addr); return 1; } if (op == DW_OP_call2) @@ -8570,6 +8570,9 @@ adjust_exprloc (dw_cu_ref cu, dw_die_ref die, dw_cu_ref refcu, { ptr -= 4; write_32 (ptr, refd->u.p2.die_new_offset); + + if (op == DW_OP_GNU_parameter_ref) + fprintf (stderr, "new DW_OP_GNU_parameter_ref offset: %d\n", refd->u.p2.die_new_offset); } break; case DW_OP_const4u: One can see: $ ~/Programming/dwz/dwz clang_delta new DW_OP_GNU_parameter_ref offset: 36517968 new DW_OP_GNU_parameter_ref offset: 36972704 new DW_OP_GNU_parameter_ref offset: 62741640 new DW_OP_GNU_parameter_ref offset: 154319544 new DW_OP_GNU_parameter_ref offset: 152650728 new DW_OP_GNU_parameter_ref offset: 74420200 new DW_OP_GNU_parameter_ref offset: 107181864 new DW_OP_GNU_parameter_ref offset: 108290664 new DW_OP_GNU_parameter_ref offset: 156920840 new DW_OP_GNU_parameter_ref offset: 80663008 new DW_OP_GNU_parameter_ref offset: 80986608 new DW_OP_GNU_parameter_ref offset: 107000824 new DW_OP_GNU_parameter_ref offset: 107601176 new DW_OP_GNU_parameter_ref offset: 62875880 new DW_OP_GNU_parameter_ref offset: 156353768 new DW_OP_GNU_parameter_ref offset: 249005760 new DW_OP_GNU_parameter_ref offset: 83816472 new DW_OP_GNU_parameter_ref offset: 74428552 new DW_OP_GNU_parameter_ref offset: 84197752 new DW_OP_GNU_parameter_ref offset: 249207840 new DW_OP_GNU_parameter_ref offset: 107038104 new DW_OP_GNU_parameter_ref offset: 107713416 new DW_OP_GNU_parameter_ref offset: 153695672 new DW_OP_GNU_parameter_ref offset: 156679976 $ ~/Programming/dwz/dwz clang_delta /home/marxin/Programming/dwz/dwz: clang_delta: Couldn't find DIE referenced by DW_OP_GNU_parameter_ref, offset: 36517968 Which means the first DW_OP_GNU_parameter_ref offset is broken and it should be possible to debug that.
This message is a reminder that Fedora 27 is nearing its end of life. On 2018-Nov-30 Fedora will stop maintaining and issuing updates for Fedora 27. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '27'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 27 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
This was never fully understood and should be investigated a bit more. Although it might be an issue with the DWARF generated by GCC
Fixed by tentative patch for https://sourceware.org/bugzilla/show_bug.cgi?id=24204.
It should be fixed by upstream 0.13.
(In reply to Jan Kratochvil from comment #18) > It should be fixed by upstream 0.13. dwz-0.13-6 is in rawhide now.