Re: [gold patch] GDB index 1/2: Add new DWARF declarations

[Cary Coutant <ccoutant at google dot com>]

> Actually you might want to consider putting these on the binutils 2.22
> branch also, since it looks like they will be needed to get good error
> messages from gold when using -gdwarf-4.

By themselves, these changes won't do anything to improve gold's
handling of DWARF-4 -- all they do is add declarations. The changes in
reduced_debug_output.cc are just to squash a warning from the compiler
about missing cases in the switch, but I got to wondering why the new
DW_LINE_EXTENDED_OPS didn't trigger the same compiler warning in
Sized_dwarf_line_info::process_one_opcode. It turns out that
extended_op is declared as unsigned char instead of
elfcpp::DW_LINE_EXTENDED_OPS. That's OK, I guess -- I could declare it
as the enum type and add a default case to that switch if you like,
but that got me looking at the code to process DW_LNE_define_file. For
each string it reads, it adds the string length to oplen. This is
wrong! The extended_op_len that we read covers the entire instruction
(except for the first byte and the length itself) [cf. Section 6.2.3
of the DWARF-4 spec]. It would be a good sanity check, perhaps, to
tally up the lengths of the strings for that instruction and match
them against extended_op_len, but nothing more.

Anyway, as far as reading DWARF-4 goes, I think we're good. The new
FORM codes don't affect anything before the gdb-index patch, since all
we read prior to that is the line number program. The new extended
line opcodes should be fine -- we ignore them silently and correctly
(by simply skipping extended_op_len extra bytes).

I'll submit a follow-on patch to fix the handling of
DW_LNE_define_file, unless you know of a reason why it should remain
as is (a bug in the compiler?). As far as I can tell, it works simply
because we never see this opcode.

-cary