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
works on other architectures
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?
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.
(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.
Propose to close as resolved-notabug. I don't see what dwz could do better here.
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?
Created attachment 13281 [details] preprocessed source
(In reply to Matthias Klose from comment #7) > Created attachment 13281 [details] > preprocessed source I'm reducing that right now..
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.
Compiled with -O2 -g
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.
This is a GCC bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99388