[PATCH] D44562: [ELF] Rework debug line parsing to use llvm::Error and callbacks (LLD-side)

[Rafael Avila de Espindola via llvm-commits]

David Blaikie via llvm-commits <llvm-commits at lists.llvm.org> writes:

> On Mon, Mar 19, 2018 at 2:24 PM Rafael Avila de Espindola via Phabricator <
> reviews at reviews.llvm.org> wrote:
>
>> espindola added inline comments.
>>
>>
>> ================
>> Comment at: test/ELF/undef.s:37
>>
>> +# CHECK: warning: parsing line table prologue at 0x00000000 should have
>> ended at 0x00000038 but it ended at 0x00000037
>>  # CHECK: error: undefined symbol: zed6
>> ----------------
>> I think I agree with George about producing an error on corrupted output.
>> In practice we expect to never see it, so we may as well make the code
>> simpler.
>>
>
> Seems like it'd be unfortunate if you had a shipped binary library with
> some bogus DWARF (or, say, we had a bug in the DWARF parser that caused a
> parse failure?) & you had linker errors you couldn't diagnose because the
> linker just told you about the bogus DWARF but not about the missing symbol
> you could act on (by, say, linking in some other library you forgot to pass
> to the linker?)? (if I'm understanding correctly here that you're
> suggesting erroring on the bogus DWARF and stopping there/not providing the
> undefined symbol error?)

No, you would still get an error like

./build/bin/ld.lld: error: undefined symbol: foo
>>> referenced by test.o:(.data+0x0)
.... something about not being able to parse the debug info....

Now that I think of it, the fact that lld could not parse the debug info
to provide a better error message should always be a note, not an
error, regardless of how broken the section happens to be.

Cheers,
Rafael