Re: ld error message %C format

[Ian Lance Taylor <iant at google dot com>]

Alan Modra <amodra@gmail.com> writes:

> On Wed, May 18, 2011 at 04:59:07PM -0700, Ian Lance Taylor wrote:
>> Alan Modra <amodra@gmail.com> writes:
>> 
>> > How do people feel about extending typical linker error messages like
>> > the following
>> > 	tmpdir/dump0.o: In function `foo':
>> > 	./compressed1.c:13: undefined reference to `bar'
>> > to always include the section and offset information?
>> > 	tmpdir/dump0.o: In function `foo':
>> > 	./compressed1.c:13:(.text+0x8): undefined reference to `bar'
>> >
>> > When debugging toolchain problems, the section and offset is often
>> > more useful than the source information.  I've checked that this
>> > change doesn't seem to break emacs parsing of error messages.
>> 
>> While I'm generally not happy about adding options, I think this is a
>> case where we should consider it.  That is, consider an option
>> requesting more verbose information from linker errors.  I think that
>> for ordinary users of the linker, i.e., 99.9% of linker users, the
>> section+offset will be far more confusing than helpful.
>
> Perhaps I should give some more background as to why I'd like to make
> this change.  Current uses of %C are
> - multiple definition error
> - warning symbol call-back
> - undefined symbol error
> - reloc overflow/dangerous/unattached errors
> - cross reference error
> - one use in each of pe.em, pep.em, pe-dll.c
> - two uses in each of elf64-ppc.c, elf32-ppc.c, elf32-sh.c
>
> I'd say that some of these existing uses of %C would benefit from the
> extra information, particularly the reloc and cross ref errors.  Also,
> it's not as if emitting section+offset is entirely new:  You get that
> for all of these errors if debug info is missing.  However, the main
> reason I want the section+offset is for replacing uses of
> _bfd_error_handler with info->callbacks->einfo in BFD back-end linker
> support functions.  Some of these already report section+offset.  I
> don't like to idea of removing information..
>
> einfo is attractive for the source function and line info, and %v for
> offset doesn't truncate like %lx for 32-bit host, 64-bit target.

It's specifically the multiple definition error and the undefined symbol
error where I think we should tread carefully.  Those are the cases
which people will see routinely, and the information about be presented
in a way that makes sense and is easy to use for people who know nothing
about linkers.  I agree that it is somewhat odd to remove information,
but I've gotten complaints about verbose linker error messages.  And, of
course, it's a very common complaint about g++'s error messages.  It's
hard to know what the right balance is, but I'm pretty sure that
presenting all information by default is not it.

But I won't continue this conversation farther; you should proceed as
you see best.

Ian