We has precompiled object with unsupported FDE version (=2).
It is possible to use llvm-mc instead for this test.
Patch do this change.
llvm-svn: 335818
I don't think we have to aim for precise bug compatibility.
We can return a nullptr if a section is consumed by the linker, and
the rest should naturally work.
llvm-svn: 316817
Since yaml2obj is now able to parse integer values as relocation types,
there is no need to keep hex edited elf object for this test,
we can produce it on fly, just like this patch do.
Differential revision: https://reviews.llvm.org/D34893
llvm-svn: 307032
This is last known noticable fatal() in target.cpp.
We also have other ones for unknown relocations or
creating unknown targets, but that one can be just error I think.
Used yaml2obj to generate test.
Differential revision: https://reviews.llvm.org/D28049
llvm-svn: 290335
We probably would want to avoid fatal() if we can in context of librarification,
but for me reason of that patch is to help D27900 go.
D27900 changes errors reporting to something like
error: text1
note: text2
note: text3
where hint used to provide additional information about location. In that case
I can't just call fatal() because user will not see notes after that what adds additional complication to handle.
So It is good to switch fatal() to error() where it is possible.
Also it adds testcase with broken relocation number.
Previously we did not have any, It checks that error() instead of fatal() works fine.
Differential revision: https://reviews.llvm.org/D27973
llvm-svn: 290239
It was requested on review for https://reviews.llvm.org/D25090 to add testcase in lld.
Spec says (http://www.sco.com/developers/gabi/1998-04-29/ch4.eheader.html) :
e_shnum
This member holds the number of entries in the section header table.
Thus the product of e_shentsize and e_shnum gives the section header table's size in bytes.
If a file has no section header table, e_shnum holds the value zero.
In case revealed, broken input did not contain zero in this field.
LLD then could crash when proccessed sections (returned array has incorrect size):
template <class ELFT> void SharedFile<ELFT>::parseSoName() {
...
for (const Elf_Shdr &Sec : Obj.sections()) {
...
llvm-svn: 284375
This part was splitted from D25016.
When sh_info value was set in the way that non-local symbol was treated as local, lld
was asserting, patch fixes that.
Differential revision: https://reviews.llvm.org/D25371
llvm-svn: 283859
With fix: commit changes from InputFiles.cpp too.
Original commit message:
We have following code in lld, that truncates the alignment value to 32 bit. Big alignment in this case
may give result 0 and crash later.
template <class ELFT>
CommonInputSection<ELFT>::CommonInputSection(std::vector<DefinedCommon *> Syms)
: InputSection<ELFT>(nullptr, &Hdr, "") {
....
for (DefinedCommon *Sym : Syms) {
this->Alignment = std::max<uintX_t>(this->Alignment, Sym->Alignment);
...
}
}
Patch fixes the issue.
Differential revision: https://reviews.llvm.org/D25235
llvm-svn: 283738
We have following code in lld, that truncates the alignment value to 32 bit. Big alignment in this case
may give result 0 and crash later.
template <class ELFT>
CommonInputSection<ELFT>::CommonInputSection(std::vector<DefinedCommon *> Syms)
: InputSection<ELFT>(nullptr, &Hdr, "") {
....
for (DefinedCommon *Sym : Syms) {
this->Alignment = std::max<uintX_t>(this->Alignment, Sym->Alignment);
...
}
}
Patch fixes the issue.
Differential revision: https://reviews.llvm.org/D25235
llvm-svn: 283733
When sh_info of sumbol table value was set to zero, lld was asserting.
Patch fixes the issue.
Differential revision: https://reviews.llvm.org/D25016
llvm-svn: 283562
I found that this check still may be useful in some cases.
At fact since we use uint32_t alignment, then maximum value
that is valid for us is 0x80000000. But some broken files,
for example file from testcase may have greater value.
Because of that offset calculation overflow and crash happens.
Differential revision: https://reviews.llvm.org/D25324
llvm-svn: 283544
Previously if sh_size of dynamic section was broken,
lld may crash. Or even may not crash if used 32 bits host.
(then value may be truncated to 32 bits when doing pointer arithmetic
and could be just zero).
Patch fixes the issue.
Differential revision: https://reviews.llvm.org/D25327
llvm-svn: 283533
createELFObj() may call error(...), for example when file is too short.
In that case header is not set and following line lead to crash:
EMachine = ELFObj.getHeader()->e_machine;
Patch fixes the issue.
Differential revision: https://reviews.llvm.org/D25233
llvm-svn: 283532
This patch makes the check for null section stricter,
so it is only allowed for STT_SECTION symbols now.
Differential revision: https://reviews.llvm.org/D25231
llvm-svn: 283426
Previously lld would hang in infinite loop in this case,
patch fixes the issue. Object was found during AFL run.
Differential revision: https://reviews.llvm.org/D25229
llvm-svn: 283208
Relative to PR30540.
If .symtab has invalid type in elf, no bodies are created and any relocation
that tries to access them will fail.
The same can happen if symbol index is just incorrect.
This was revealed by "id_000005,sig_11,src_000000,op_flip2,pos_420"
Differential revision: https://reviews.llvm.org/D25025
llvm-svn: 283201
id_000021,sig_11,src_000002,op_flip1,pos_92 from PR30540
does not have TLS sections, but type
of one of the symbol is broken and set to STT_TLS,
what resulted in a crash. Patch fixes crash.
DIfferential revision: https://reviews.llvm.org/D25083
llvm-svn: 283198
Testcase contains a common symbol with zero alignment,
previously lld would crash, patch fixes that.
Differential revision: https://reviews.llvm.org/D25085
llvm-svn: 283197
George Rimar