Previous error message style:
error: /home/alice/src/bar.c:12: relocation R_X86_64_PLT32 cannot refer to absolute symbol 'answer' defined in /home/alice/src/foo.o
New error message style:
error: relocation R_X86_64_PLT32 cannot refer to absolute symbol: foo
>>> defined in /home/alice/src/foo.o
>>> referenced by bar.c:12 (/home/alice/src/bar.c:12)
>>> /home/alice/src/bar.o:(.text+0x1)
llvm-svn: 299390
LLD's error messages contain line numbers, function names or section names.
Currently they are formatter as follows.
foo.c (32): symbol 'foo' not found
foo.c (function bar): symbol 'foo' not found
foo.c (.text+0x1234): symbol 'foo' not found
This patch changes them so that they are consistent with Clang's output.
foo.c:32: symbol 'foo' not found
foo.c:(function bar): symbol 'foo' not found
foo.c:(.text+0x1234): symbol 'foo' not found
Differential Revision: https://reviews.llvm.org/D26901
llvm-svn: 287537
We should always include symbol name when reporting relocations
error to simplify debugging of these issues. Without symbol names
users have to manually investigate which of the libraries contain
invalid relocations which can be cumbersome when linking multiple
libraries.
Differential Revision: https://reviews.llvm.org/D23690
llvm-svn: 279162
It was reported in PR28020, that lld does not link code which
gold do. But in fact that is expected behavior as we do not
support DT_TEXTREL.
This patch changes error message as it can report about relocations against
text segments exclusively, other dynamic relocations errors can
be handled separately.
Differential revision: http://reviews.llvm.org/D21133
llvm-svn: 272377
These would just crash at runtime.
If we ever decide to support rw text segments this should make it easier
to implement as there is now a single point where we notice the problem.
I have tested this with a freebsd buildworld. It found a non pic
assembly file being linked into a .so,. With that fixed, buildworld
finished.
llvm-svn: 268149
This requires knowing input section offsets in output sections before
scanRelocs. This is generally a good thing and should allow further
simplifications in the creation of dynamic relocations.
llvm-svn: 265673
Fangrui Song