Case was revealed by id_000010,sig_08,src_000000,op_havoc,rep_4 from PR30540.
Out implementation uses uint32 for storing section alignment value,
what seems reasonable, though if value exceeds 32 bits bounds we have
truncation and final value of 0.
Patch fixes the issue.
Differential revision: https://reviews.llvm.org/D25082
llvm-svn: 283097
Header(Hdr), File(File), Repl(this) {
// The ELF spec states that a value of 0 means the section has
// no alignment constraits.
+ if (Header->sh_addralign > UINT32_MAX)
+ fatal(getFilename(File) + ": section sh_addralign is too large");
Alignment = std::max<uintX_t>(Header->sh_addralign, 1);
}
--- /dev/null
+# RUN: yaml2obj %s -o %t
+# RUN: not ld.lld %t -o %tout 2>&1 | FileCheck %s
+
+## In current lld implementation, we do not accept sh_addralign
+## larger than UINT32_MAX.
+!ELF
+FileHeader:
+ Class: ELFCLASS64
+ Data: ELFDATA2LSB
+ Type: ET_REL
+ Machine: EM_X86_64
+Sections:
+ - Name: .text
+ Type: SHT_PROGBITS
+ Flags: [ SHF_ALLOC, SHF_EXECINSTR ]
+ AddressAlign: 0x1000000000000001
+ Content: "00000000"
+
+# CHECK: section sh_addralign is too large