| Message ID | 20210118184344.GZ1034503@tucnak |
|---|---|
| State | New |
| Headers | show |
| Series | libbacktrace: Fix up DWARF5 .debug_line handling [PR98716] | expand |
On Mon, Jan 18, 2021 at 10:44 AM Jakub Jelinek via Gcc-patches <gcc-patches@gcc.gnu.org> wrote: > > When GCC (since the switch to -gdwarf-5 by default) is configured and built > against recent binutils (2.35.1 if slightly patched, or 2.36 or trunk), > the assembler emits DWARF5 .debug_line rather than DWARF4 or older > .debug_line. > > Seems some DWARF5 support has been added to libbacktrace, but there is one > problem. The DWARF5 spec (like DWARF4 spec) says that the initial value of > file is 1, but unlike DWARF4 and earlier which had in the filename table > entries starting with 1, DWARF5 has an 0 entry before that (which is > supposed to match DW_AT_name and DW_AT_comps_dir pair in the .debug_info > CU). > > The following patch fixes that. > > On i686-linux when built against those new binutils this fixes (the > c-c++-common tests for both C and C++): > -FAIL: c-c++-common/asan/alloca_big_alignment.c -O2 -flto -fno-use-linker-plugin -flto-partition=none output pattern test > -FAIL: c-c++-common/asan/alloca_big_alignment.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects output pattern test > -FAIL: c-c++-common/asan/alloca_detect_custom_size.c -O2 -flto -fno-use-linker-plugin -flto-partition=none output pattern test > -FAIL: c-c++-common/asan/alloca_detect_custom_size.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects output pattern test > -FAIL: c-c++-common/asan/alloca_overflow_partial.c -O2 -flto -fno-use-linker-plugin -flto-partition=none output pattern test > -FAIL: c-c++-common/asan/alloca_overflow_partial.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects output pattern test > -FAIL: c-c++-common/asan/alloca_overflow_right.c -O2 -flto -fno-use-linker-plugin -flto-partition=none output pattern test > -FAIL: c-c++-common/asan/alloca_overflow_right.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects output pattern test > -FAIL: c-c++-common/asan/alloca_underflow_left.c -O2 -flto -fno-use-linker-plugin -flto-partition=none output pattern test > -FAIL: c-c++-common/asan/alloca_underflow_left.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects output pattern test > -FAIL: c-c++-common/asan/global-overflow-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none output pattern test > -FAIL: c-c++-common/asan/global-overflow-1.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects output pattern test > -FAIL: c-c++-common/asan/heap-overflow-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none output pattern test > -FAIL: c-c++-common/asan/heap-overflow-1.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects output pattern test > -FAIL: c-c++-common/asan/null-deref-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none output pattern test > -FAIL: c-c++-common/asan/null-deref-1.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects output pattern test > -FAIL: c-c++-common/asan/sanity-check-pure-c-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none output pattern test > -FAIL: c-c++-common/asan/sanity-check-pure-c-1.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects output pattern test > -FAIL: c-c++-common/asan/stack-overflow-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none output pattern test > -FAIL: c-c++-common/asan/stack-overflow-1.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects output pattern test > -FAIL: c-c++-common/asan/strncpy-overflow-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none output pattern test > -FAIL: c-c++-common/asan/strncpy-overflow-1.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects output pattern test > -FAIL: c-c++-common/asan/use-after-free-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none output pattern test > -FAIL: c-c++-common/asan/use-after-free-1.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects output pattern test > -FAIL: g++.dg/asan/large-func-test-1.C -O2 -flto -fno-use-linker-plugin -flto-partition=none output pattern test > -FAIL: g++.dg/asan/large-func-test-1.C -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects output pattern test > -FAIL: TestCaller > > Bootstrapped/regtested on x86_64-linux and i686-linux (2.35.1 binutils but > not patched) and i686-linux (latest binutils), x86_64-linux regtest still > pending, ok for trunk? > > 2021-01-18 Jakub Jelinek <jakub@redhat.com> > > PR debug/98716 > * dwarf.c (read_line_program): For DWARF5 .debug_line headers, > start with hdr->filenames[1] rather than hdr->filenames[0]. > > --- libbacktrace/dwarf.c.jj 2021-01-04 10:25:53.495067802 +0100 > +++ libbacktrace/dwarf.c 2021-01-18 14:27:05.034589998 +0100 > @@ -2715,8 +2715,11 @@ read_line_program (struct backtrace_stat > > address = 0; > op_index = 0; > - if (hdr->filenames_count > 0) > - reset_filename = hdr->filenames[0]; > + /* The initial file is file with index 1. In DWARF4 and earlier > + filename table starts with entry 1, while in DWARF5 it starts > + with entry 0 which should match the CU's DW_AT_name attribute. */ > + if (hdr->filenames_count > (hdr->version >= 5)) > + reset_filename = hdr->filenames[hdr->version >= 5]; > else > reset_filename = ""; > filename = reset_filename; Thanks, but I think more changes are needed. Looking up entries in the filenames array will be off by one for DWARF 5 in other places as well, specifically when handling DW_LNS_set_file and DW_AT_call_file. I'm testing a larger patch now. Ian
On Mon, Jan 18, 2021 at 12:11:02PM -0800, Ian Lance Taylor wrote: > Thanks, but I think more changes are needed. Looking up entries in > the filenames array will be off by one for DWARF 5 in other places as > well, specifically when handling DW_LNS_set_file and DW_AT_call_file. > I'm testing a larger patch now. You're right, sorry for missing that spot. Jakub
--- libbacktrace/dwarf.c.jj 2021-01-04 10:25:53.495067802 +0100 +++ libbacktrace/dwarf.c 2021-01-18 14:27:05.034589998 +0100 @@ -2715,8 +2715,11 @@ read_line_program (struct backtrace_stat address = 0; op_index = 0; - if (hdr->filenames_count > 0) - reset_filename = hdr->filenames[0]; + /* The initial file is file with index 1. In DWARF4 and earlier + filename table starts with entry 1, while in DWARF5 it starts + with entry 0 which should match the CU's DW_AT_name attribute. */ + if (hdr->filenames_count > (hdr->version >= 5)) + reset_filename = hdr->filenames[hdr->version >= 5]; else reset_filename = ""; filename = reset_filename;