Bug 1564880 - Couldn't find DIE referenced by DW_OP_GNU_parameter_ref
Summary: Couldn't find DIE referenced by DW_OP_GNU_parameter_ref
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: dwz
Version: rawhide
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-04-08 15:41 UTC by Jan Kratochvil
Modified: 2021-01-21 19:12 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-01-21 19:12:09 UTC
Type: Bug


Attachments (Terms of Use)

Description Jan Kratochvil 2018-04-08 15:41:08 UTC
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.

Comment 1 Jan Kratochvil 2018-04-08 15:43:38 UTC
Yes, it was: dwz-0.12-5.fc27.x86_64

Comment 2 Mark Wielaard 2018-04-09 09:05:44 UTC
Is the liblldb.so.7.0.0-7.0.0-0.20180406snap0.fc27.x86_64.debug that caused the issue available somewhere for inspection?

Comment 3 Jan Kratochvil 2018-04-09 20:29:04 UTC
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

Comment 4 Mark Wielaard 2018-04-11 12:29:02 UTC
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.

Comment 5 Mark Wielaard 2018-04-11 12:45:13 UTC
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]

Comment 6 Mark Wielaard 2018-04-12 12:39:01 UTC
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?

Comment 7 Jan Kratochvil 2018-04-12 15:45:50 UTC
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.

Comment 8 Jan Kratochvil 2018-04-12 17:39:41 UTC
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

Comment 9 Mark Wielaard 2018-04-12 21:35:06 UTC
(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.

Comment 10 Jan Kratochvil 2018-04-13 05:44:26 UTC
(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.

Comment 11 Martin Liška 2018-08-21 12:04:33 UTC
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

Comment 12 Jan Kratochvil 2018-08-21 12:14:30 UTC
(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)

Comment 14 Martin Liška 2018-10-02 08:06:47 UTC
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.

Comment 15 Ben Cotton 2018-11-27 14:11:13 UTC
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.

Comment 16 Mark Wielaard 2018-11-28 19:08:19 UTC
This was never fully understood and should be investigated a bit more. Although it might be an issue with the DWARF generated by GCC

Comment 17 Tom de Vries 2019-03-07 14:24:02 UTC
Fixed by tentative patch for https://sourceware.org/bugzilla/show_bug.cgi?id=24204.

Comment 18 Jan Kratochvil 2019-09-26 11:30:56 UTC
It should be fixed by upstream 0.13.

Comment 19 Mark Wielaard 2021-01-21 19:12:09 UTC
(In reply to Jan Kratochvil from comment #18)
> It should be fixed by upstream 0.13.

dwz-0.13-6 is in rawhide now.


Note You need to log in before you can comment on or make changes to this bug.