Cary Coutant <ccoutant at gmail dot com> changed:

           What    |Removed                     |Added
             Status|NEW                         |ASSIGNED

--- Comment #7 from Cary Coutant <ccoutant at gmail dot com> ---
Unfortunately, gold was never taught to read DWARF-4 line number tables,
because GCC and gas still always use version 2. Here's what's happening:

(1) When reading the line number program header, gold doesn't read the "maximum
operations per instruction" field, and instead reads that field as "default

(2) The remaining fields of the header are also read offset by one byte,
including the standard opcode lengths array, the include directories list, and
the file names list.

(3) It starts reading the line number program correctly, because it uses the
prologue length field from the header to find the beginning.

(4) Later, when reading the line number program, when it sees an opcode it
doesn't care about (namely, set_prologue_end), it gets a bogus value from the
standard opcode lengths table, and skips an LEB128 that really isn't part of
that opcode.

(5) That screws up the reading of subsequent opcodes, and it reads a data field
as if it were an opcode, setting a bogus file number which gets saved as part
of a line number table row.

(6) Later, when looking up an address, it tries to translate the bogus file
number to a file name, and hits the assertion. (Which really shouldn't be an
assertion, because this can be caused by bogus input rather than a bug in gold,
even though it's really a bug here.)

The fix here is to check the line table version number, and read the extra
field that was added in DWARF version 4. Since gold doesn't support Itanium
(yet), I'll probably just error out if that field is anything other than 1.

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

Reply via email to