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

[David Blaikie via llvm-commits]

On Mon, Mar 19, 2018 at 2:57 PM Rafael Avila de Espindola <
rafael.espindola at gmail.com> wrote:

> 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....
>

Ah, cool!


> 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.
>

Yeah, sounds fair to me. (for building gdb-index, say, that'd probably be
an error - but yeah, just parsing it to improve diagnostic quality doesn't
seem like it warrants an error on parse failure)


>
> Cheers,
> Rafael
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20180319/09d18dc2/attachment-0001.html>