[Bug symtab/26333] New: Complain more informatively when encountering vendor-specific line number instructions

[Bug symtab/26333] New: Complain more informatively when encountering vendor-specific line number instructions

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=26333

            Bug ID: 26333
           Summary: Complain more informatively when encountering
                    vendor-specific line number instructions
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: symtab
          Assignee: unassigned at sourceware dot org
          Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

AFAIU, there are two ways to define vendor-specific extensions in the line
number program.

Vendor-specific standard opcodes (increase opcode_base).

Vendor-specific extended opcodes (DW_LNE_lo_user - DW_LNE_hi_user).

When encountering DW_LNE_hi_user, we run into:
...
During symbol reading: mangled .debug_line section
...

That could be a bit more informatively, like:
...
During symbol reading: .debug_line section with vendor-specific extensions,
abandoning
...

[ In the spec, we have at standard_opcode_lengths:
...
By increasing opcode_base, and adding elements to this array, new standard
opcodes can be added, while allowing consumers who do not know about these new
opcodes to be able to skip them.
...

I think the skipping here refers to the possibility to continue decoding the
opcode stream, which is useful for f.i. readelf -Wl or some such.  But I don't
think gdb can do much more than bail out, given that it has no idea what the
effect of the extension should be. ]

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/26333] Complain more informatively when encountering vendor-specific line number instructions

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=26333

Tom de Vries <vries at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/26333] Complain more informatively when encountering vendor-specific line number instructions

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=26333

--- Comment #1 from Tom de Vries <vries at gcc dot gnu.org> ---
Created attachment 12743
  --> https://sourceware.org/bugzilla/attachment.cgi?id=12743&action=edit
gzipped exec containing DW_LNE_hi_user

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/26333] Complain more informatively when encountering vendor-specific line number instructions

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=26333

--- Comment #2 from Tom de Vries <vries at gcc dot gnu.org> ---
Tentative patch for vendor-specific extended opcode:
...
diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c
index 4e70dccecb..bdba0956f3 100644
--- a/gdb/dwarf2/read.c
+++ b/gdb/dwarf2/read.c
@@ -20591,6 +20591,13 @@ dwarf_decode_lines_1 (struct line_header *lh, struct
dwarf2_c
u *cu,
              extended_end = line_ptr + extended_len;
              extended_op = read_1_byte (abfd, line_ptr);
              line_ptr += 1;
+             if (DW_LNE_lo_user <= extended_op
+                 && extended_op <= DW_LNE_hi_user)
+               {
+                 complaint (_(".debug_line section with vendor-specific "
+                              "extended opcode, abandoning"));
+                 return;
+               }
              switch (extended_op)
                {
                case DW_LNE_end_sequence:
...

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/26333] vendor-specific extended line number opcodes are not skipped as they should be

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=26333

Tom de Vries <vries at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Complain more informatively |vendor-specific extended
                   |when encountering           |line number opcodes are not
                   |vendor-specific line number |skipped as they should be
                   |instructions                |

--- Comment #3 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #0)
> [ In the spec, we have at standard_opcode_lengths:
> ...
> By increasing opcode_base, and adding elements to this array, new standard
> opcodes can be added, while allowing consumers who do not know about these
> new opcodes to be able to skip them.
> ...
> 
> I think the skipping here refers to the possibility to continue decoding the
> opcode stream, which is useful for f.i. readelf -Wl or some such.  But I
> don't think gdb can do much more than bail out, given that it has no idea
> what the effect of the extension should be. ]

Hmm, but for the vendor-specific standard opcodes, we do ignore them:
...
            default:
              {
                /* Unknown standard opcode, ignore it.  */
                int i;

                for (i = 0; i < lh->standard_opcode_lengths[op_code]; i++)
                  {
                    (void) read_unsigned_leb128 (abfd, line_ptr, &bytes_read);
                    line_ptr += bytes_read;
                  }
              }    
...

[ FTR, added here (
https://sourceware.org/legacy-ml/binutils/2001-11/msg00279.html ). ]

OK, this is the bit of the standard I was missing (7.1 Vendor Extensibility):
...
To ensure that extensions added by one vendor may be safely ignored by
consumers that do not understand those extensions, the following rules should
be followed:
1.
New attributes should be added in such a way that a debugger may recognize the
format of a new attribute value without knowing the content of that attribute
value.
2.
The semantics of any new attributes should not alter the semantics of
previously existing attributes.
3.
The semantics of any new tags should not conflict with the semantics of
previously existing tags.
...

Updating summary.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/26333] vendor-specific extended line number opcodes are not skipped as they should be

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=26333

Tom de Vries <vries at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|enhancement                 |minor

--- Comment #4 from Tom de Vries <vries at gcc dot gnu.org> ---
Tentative patch:
...
diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c
index 4e70dccecb..bcbffbf0e8 100644
--- a/gdb/dwarf2/read.c
+++ b/gdb/dwarf2/read.c
@@ -20591,6 +20591,13 @@ dwarf_decode_lines_1 (struct line_header *lh, struct
dwarf2_c
u *cu,
              extended_end = line_ptr + extended_len;
              extended_op = read_1_byte (abfd, line_ptr);
              line_ptr += 1;
+             if (DW_LNE_lo_user <= extended_op
+                 && extended_op <= DW_LNE_hi_user)
+               {
+                 /* Vendor extension, ignore.  */
+                 line_ptr = extended_end;
+                 break;
+               }
              switch (extended_op)
                {
                case DW_LNE_end_sequence:
...

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/26333] vendor-specific extended line number opcodes are not skipped as they should be

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=26333

--- Comment #5 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #4)
> Tentative patch:

Using the tentative patch, I manage to set a breakpoint now:
...
$ gdb test
Reading symbols from test...
(gdb) break test.zig:2
Breakpoint 1 at 0x800000b: file test.zig, line 2.
(gdb)
...

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/26333] vendor-specific extended line number opcodes are not skipped as they should be

[cvs-commit at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=26333

--- Comment #6 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Tom de Vries <vries@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=8f34b74686c6b9bf83d1c46e93b5aecca2e0ed0e

commit 8f34b74686c6b9bf83d1c46e93b5aecca2e0ed0e
Author: Tom de Vries <tdevries@suse.de>
Date:   Mon Aug 3 16:59:20 2020 +0200

    [gdb/symtab] Ignore DW_LNE_lo_user/DW_LNE_hi_user range

    When reading an exec with a .debug_line section containing a
vendor-specific
    extended opcode, we get:
    ...
    $ gdb -batch -iex "set complaints 10" dw2-vendor-extended-opcode
    During symbol reading: mangled .debug_line section
    ...
    and reading of the .debug_line section is abandoned.

    The vendor-specific extended opcode should be ignored, as specified in the
    DWARF standard (7.1 Vendor Extensibility).  [ FWIW, vendor-specific
    standard opcodes are already ignored. ]

    Fix this by ignoring all vendor-specific extended opcodes.

    Build and tested on x86_64-linux.

    gdb/ChangeLog:

    2020-08-03  Tom de Vries  <tdevries@suse.de>

            PR symtab/26333
            * dwarf2/read.c (dwarf_decode_lines_1): Ignore
            DW_LNE_lo_user/DW_LNE_hi_user range.

    gdb/testsuite/ChangeLog:

    2020-08-03  Tom de Vries  <tdevries@suse.de>

            PR symtab/26333
            * lib/dwarf.exp (DW_LNE_user): New proc.
            * gdb.dwarf2/dw2-vendor-extended-opcode.c: New test.
            * gdb.dwarf2/dw2-vendor-extended-opcode.exp: New file.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/26333] vendor-specific extended line number opcodes are not skipped as they should be

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=26333

Tom de Vries <vries at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |10.1
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #7 from Tom de Vries <vries at gcc dot gnu.org> ---
Patch with test-case committed, marking resolved-fixed.

-- 
You are receiving this mail because:
You are on the CC list for the bug.