Bug 27449 - dwz: 1: Unknown DWARF DW_OP_0
Summary: dwz: 1: Unknown DWARF DW_OP_0
Status: RESOLVED MOVED
Alias: None
Product: dwz
Classification: Unclassified
Component: default (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-02-21 11:43 UTC by Matthias Klose
Modified: 2021-03-04 15:05 UTC (History)
4 users (show)

See Also:
Host:
Target: aarch64-linux-gnu
Build:
Last reconfirmed:


Attachments
preprocessed source (321.80 KB, application/x-xz)
2021-03-04 08:12 UTC, Matthias Klose
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Matthias Klose 2021-02-21 11:43:31 UTC
dwz trunk 20210219 on aarch64-linux-gnu (building the olive-editor package):

$ dwz -molive-editor.debug -Molive-editor.debug -- 1 2
dwz: 1: Unknown DWARF DW_OP_0
dwz: Too few files for multifile optimization

test case at
https://people.debian.org/~doko/tmp/tst-dwz.tar.xz
Comment 1 Matthias Klose 2021-02-21 11:44:10 UTC
works on other architectures
Comment 2 Mark Wielaard 2021-02-21 17:14:04 UTC
I added some extra error output in commit 4705796eb "Add DIE offsets in error messages to make it easier to find what is wrong" with that you get:

dwz: 1: Unknown DWARF DW_OP_0 referenced from DIE at [3d2787]

Looking at that DIE:

 [3d2787]              variable             abbrev: 50
                       abstract_origin      (ref4) [3d8fe0]
                       location             (sec_offset) location list [12e381]
                       GNU_locviews         (sec_offset) location list [12e37f]

Which is part of:

 Compilation unit at offset 3684967:
 Version: 4, Abbreviation section offset: 33924, Address size: 8, Offset size: 4
 [383a72]  compile_unit         abbrev: 228
           producer             (strp) "GNU C++11 10.2.1 20210206 -mlittle-endia
n -mabi=lp64 -g -O2 -pedantic-errors -std=c++11 -fstack-protector-strong -fPIC -
fasynchronous-unwind-tables -fstack-protector-strong -fstack-clash-protection"
           language             (data1) C_plus_plus (4)
           name                 (strp) "./app/audio/audiovisualwaveform.cpp"
           comp_dir             (strp) "./obj-aarch64-linux-gnu/app"
           ranges               (sec_offset) range list [ 47da0]
           low_pc               (addr) +000000000000000000
           stmt_list            (sec_offset) 305850

Looking at the location list at 12e381 with readelf (binutils 2.35-18.fc33) and eu-readelf (elfutils 0.182) both seem to agree there is something off:

    0012e37f v000000000000003 v000000000000006 location view pair

    0012e381 v000000000000003 v000000000000006 views at 0012e37f for:
             00000000001b23a0 00000000001b23a0 (DW_OP_implicit_value 2 byte block: 0 0 )
    0012e397 v0000000000011a0 v00000000000001b views at 0012e381 for:
             0000000000000000 0604000000000000 (DW_OP_div; (Unknown location op 0x0))
    00130749 v000000000000000 v000000000000000 views at 0012e384 for:
             00000000001b2ba8 00000000001b2ba8 (DW_OP_lit2; DW_OP_stack_value) (start == end)
    0013075d <End of list>

 [12e37f] view pair 3, 6
 [12e381] range 1b23a0, 1b23a0
          +0x00000000001b23a0 <_ZN5olive19AudioVisualWaveform10DrawSampleEP8QPainterRK7QVectorINS0_16SamplePerChannelEEiii+0x110>..
          +0x00000000001b239f <_ZN5olive19AudioVisualWaveform10DrawSampleEP8QPainterRK7QVectorINS0_16SamplePerChannelEEiii+0x10f>
           [ 0] implicit_value: 2 byte block: 00 00
          range 0, 604000000000000
          +000000000000000000..
          +0x0603ffffffffffff
           [ 0] div
           [ 1] ??? (0)
           [ 2] ??? (0)
           [ 3] ??? (0)
           [ 4] ??? (0)
           [ 5] ??? (0)
           [ 6] implicit_pointer [  1b23] +0

binutils readelf seems able to recover after the DW_OP_0, but elfutils eu-readelf gets totally confused.

I think the location list expression is indeed bad, but maybe all programs are misinterpreting the location views?
Comment 3 Mark Wielaard 2021-02-26 20:12:18 UTC
Trying to track down why/how this could happen, the following might be useful:

The abstract_origin is this variable:

 [3d8fe0]        variable             abbrev: 178
                 name                 (string) "f16"
                 decl_file            (data1) qfloat16.h (11)
                 decl_line            (data1) 171
                 decl_column          (data1) 12
                 type                 (ref4) [3d8fb3]

With the following type:

 [3d8fb3]    base_type            abbrev: 80
             byte_size            (data1) 2
             encoding             (data1) float (4)
             name                 (strp) "__fp16"

This might explain why it only happens on arm, which is afaik the only arch that has __fp16 as builtin type.
Comment 4 Tom de Vries 2021-03-02 15:45:04 UTC
(In reply to Mark Wielaard from comment #2)
>     0012e37f v000000000000003 v000000000000006 location view pair
> 
>     0012e381 v000000000000003 v000000000000006 views at 0012e37f for:
>              00000000001b23a0 00000000001b23a0 (DW_OP_implicit_value 2 byte
> block: 0 0 )
>     0012e397 v0000000000011a0 v00000000000001b views at 0012e381 for:
>              0000000000000000 0604000000000000 (DW_OP_div; (Unknown location
> op 0x0))
>     00130749 v000000000000000 v000000000000000 views at 0012e384 for:
>              00000000001b2ba8 00000000001b2ba8 (DW_OP_lit2;
> DW_OP_stack_value) (start == end)
>     0013075d <End of list>

And using hex:
...
  0x0012e370 00000000 00000000 00000000 00000003
  0x0012e380 06a0231b 00000000 00a0231b 00000000
  0x0012e390 0004009e 02000000 00000000 00000000
  0x0012e3a0 00000000 000406a0 231b0000 000000a0
  0x0012e3b0 231b0000 00000002 00329f00 00000000
  0x0012e3c0 00000000 00000000 00000004 06a0231b
  0x0012e3d0 00000000 00a0231b 00000000 000600f2
...

So let's pick that apart. 

We have two addresses
...
  0x0012e381 a0231b 00000000 00a0231b 00000000
  0x0012e390 00
...
which given the .text dump look plausible.

So this is the length of the dwarf description:
...
  0x0012e391 0400
...

which is:
...
  0x0012e393 9e 020000
...
The 0x 9e is DW_OP_implicit_value. 2 is the length of the dwarf expression, which is "0x0000".  Still plausible.

The next two addresses (0000000000000000 0604000000000000) make no sense. The following length of dwarf description of 0x23a0 also not.
Comment 5 Tom de Vries 2021-03-02 15:46:01 UTC
Propose to close as resolved-notabug.

I don't see what dwz could do better here.
Comment 6 Mark Wielaard 2021-03-03 15:22:08 UTC
I agree that it almost certainly isn't a dwz bug. It appears to be a gcc DWARF generation bug. But it is hard to track down.

Matthias, would you be able to produce preprocessed sources for app/audio/audiovisualwaveform.cpp (see comment #2)? For the gcc hackers to analyze?
Comment 7 Matthias Klose 2021-03-04 08:12:27 UTC
Created attachment 13281 [details]
preprocessed source
Comment 8 Martin Liska 2021-03-04 09:36:04 UTC
(In reply to Matthias Klose from comment #7)
> Created attachment 13281 [details]
> preprocessed source

I'm reducing that right now..
Comment 9 Martin Liska 2021-03-04 10:05:45 UTC
Reduced test-case:

$ cat audiovisualwaveform.ii
void memcpy(void *) { ; }
class qfloat16 {
public:
  qfloat16(float) noexcept;
  short b16;
};
qfloat16::qfloat16(float) noexcept {
  __fp16 f16 = __fp16();
  memcpy(&f16);
}
class {
public:
  int size();
} AudioVisualWaveformDrawSample_sample;
void AudioVisualWaveformDrawSample() {
  for (int i; i < AudioVisualWaveformDrawSample_sample.size(); i++)
    qfloat16 min = 0;
}

$ readelf -w audiovisualwaveform.o >/dev/null
readelf: Warning: There is an overlap [0x42 - 0x39] in .debug_loc section.
Comment 10 Martin Liska 2021-03-04 10:11:06 UTC
Compiled with -O2 -g
Comment 11 Mark Wielaard 2021-03-04 14:43:44 UTC
With gcc (GCC) 11.0.0 20210225 on arm64 (which defaults to DWARF5) this produces:

 [   179]              variable             abbrev: 23
                       abstract_origin      (ref4) [   1ec]
                       location             (sec_offset) location list [    30]
                       GNU_locviews         (sec_offset) location list [    2e]

 [   1ec]        variable             abbrev: 7
                 name                 (string) "f16"
                 decl_file            (implicit_const) audiovisualwaveform.ii (1)
                 decl_line            (data1) 8
                 decl_column          (data1) 10
                 type                 (ref4) [   1f9]

 [   1f9]    base_type            abbrev: 2
             byte_size            (data1) 2
             encoding             (data1) float (4)
             name                 (strp) "__fp16"

DWARF section [ 8] '.debug_loclists' at offset 0x4d9:
Table at Offset 0x0:

 Length:               64
 DWARF version:         5
 Address size:          8
 Segment size:          0
 Offset entries:        0
 CU [     c] base: .text+000000000000000000 <_Z6memcpyPv>

  Offset: c, Index: 0
    view pair 0, 0

  Offset: e, Index: 2
    offset_pair 28, 40
      .text+0x0000000000000028 <_Z29AudioVisualWaveformDrawSamplev+0x18>..
      .text+0x000000000000003f <_Z29AudioVisualWaveformDrawSamplev+0x2f>
        [ 0] reg19
    end_of_list

  Offset: 14, Index: 8
    view pair 1, 6

  Offset: 16, Index: a
    offset_pair 34, 34
      .text+0x0000000000000034 <_Z29AudioVisualWaveformDrawSamplev+0x24>..
      .text+0x0000000000000033 <_Z29AudioVisualWaveformDrawSamplev+0x23>
        [ 0] implicit_value: 4 byte block: 00 00 00 00
    end_of_list

  Offset: 21, Index: 15
    view pair 1, 6

  Offset: 23, Index: 17
    offset_pair 34, 34
      .text+0x0000000000000034 <_Z29AudioVisualWaveformDrawSamplev+0x24>..
      .text+0x0000000000000033 <_Z29AudioVisualWaveformDrawSamplev+0x23>
        [ 0] implicit_pointer [   11f] +0
    end_of_list

  Offset: 2e, Index: 22
    view pair 3, 6

  Offset: 30, Index: 24
    offset_pair 34, 34
      .text+0x0000000000000034 <_Z29AudioVisualWaveformDrawSamplev+0x24>..
      .text+0x0000000000000033 <_Z29AudioVisualWaveformDrawSamplev+0x23>
        [ 0] implicit_value: 2 byte block: 00 04
    base_address 0x179a006343404
      0x000179a006343404
    end_of_list

Note that it isn't technically invalid DWARF, but the base_address is highly unlikely to be correct.
Comment 12 Mark Wielaard 2021-03-04 15:05:44 UTC
This is a GCC bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99388