RPCS3/llvm-mirror
1
0
Fork 0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-11-25 04:02:41 +01:00
Code Issues Projects Releases Wiki Activity
5ff8f4151c
llvm-mirror/test/Object/invalid-alignment.test

29 lines
710 B
Plaintext
Raw Normal View History

Check alignment in getSectionContentsAsArray. While the ArrayRef can technically have unaligned data, it would be extremely surprising if iterating over it caused undefined behavior when a reference to the underlying type was bound. llvm-svn: 319392
2017-11-30 01:44:22 +01:00
# RUN: yaml2obj %s -o %t.o
Allow unaligned access to ELF file data structures. The ELF specification says that all ELF data structures are aligned to their natural alignments both in memory and file. That means when we access mmap'ed ELF files, we could assume that all data structures are aligned properly. However, in reality, we assume that the data structures are aligned only to two bytes because .a files only guarantee that their member files are aligned to two bytes in archive files. So the data access is already unaligned. This patch relaxes the alignment requirement even more, so that we accept unaligned access to all ELF data structures. This patch in particular makes lld bug-compatible with icc. Intel C compiler doesn't seem to care about data alignment and generates unaligned relocation sections (https://bugs.llvm.org/show_bug.cgi?id=35854). I also saw another instance of compatibility issues with our internal tool which creates unaligned section headers. Because GNU linkers are not picky about alignment, looks like it is not uncommon that ELF-generating tools create unaligned files. There is a performance penalty with this patch on host machines on which unaligned access is expensive. x86 and AArch64 are fine. ARMv6 is a problem, but I don't think using ARMv6 machines as hosts is common, so I believe it's not a real problem. Differential Revision: https://reviews.llvm.org/D41978 llvm-svn: 322407
2018-01-12 23:09:19 +01:00
# RUN: llvm-readobj -r %t.o 2>&1 | FileCheck %s
Check alignment in getSectionContentsAsArray. While the ArrayRef can technically have unaligned data, it would be extremely surprising if iterating over it caused undefined behavior when a reference to the underlying type was bound. llvm-svn: 319392
2017-11-30 01:44:22 +01:00
[Object] Change ELFObjectFile<ELFT>::getFileFormatName() to use BFD names Follow-up for D74433 What the function returns are almost standard BFD names, except that "ELF" is in uppercase instead of lowercase. This patch changes "ELF" to "elf" and changes ARM/AArch64 to use their BFD names. MIPS and PPC64 have endianness differences as well, but this patch does not intend to address them. Advantages: * llvm-objdump: the "file format " line matches GNU objdump on ARM/AArch64 objects * "file format " line can be extracted and fed into llvm-objcopy -O literally. (https://github.com/ClangBuiltLinux/linux/issues/779 has such a use case) Affected tools: llvm-readobj, llvm-objdump, llvm-dwarfdump, MCJIT (internal implementation detail, not exposed) Reviewed By: jhenderson Differential Revision: https://reviews.llvm.org/D76046
2020-03-12 06:00:19 +01:00
# CHECK: Format: elf64-x86-64
Allow unaligned access to ELF file data structures. The ELF specification says that all ELF data structures are aligned to their natural alignments both in memory and file. That means when we access mmap'ed ELF files, we could assume that all data structures are aligned properly. However, in reality, we assume that the data structures are aligned only to two bytes because .a files only guarantee that their member files are aligned to two bytes in archive files. So the data access is already unaligned. This patch relaxes the alignment requirement even more, so that we accept unaligned access to all ELF data structures. This patch in particular makes lld bug-compatible with icc. Intel C compiler doesn't seem to care about data alignment and generates unaligned relocation sections (https://bugs.llvm.org/show_bug.cgi?id=35854). I also saw another instance of compatibility issues with our internal tool which creates unaligned section headers. Because GNU linkers are not picky about alignment, looks like it is not uncommon that ELF-generating tools create unaligned files. There is a performance penalty with this patch on host machines on which unaligned access is expensive. x86 and AArch64 are fine. ARMv6 is a problem, but I don't think using ARMv6 machines as hosts is common, so I believe it's not a real problem. Differential Revision: https://reviews.llvm.org/D41978 llvm-svn: 322407
2018-01-12 23:09:19 +01:00
# CHECK-NEXT: Arch: x86_64
# CHECK-NEXT: AddressSize: 64bit
# CHECK-NEXT: LoadName:
# CHECK-NEXT: Relocations [
# CHECK-NEXT: Section (2) .rela.foo {
# CHECK-NEXT: 0x0 R_X86_64_NONE - 0x0
# CHECK-NEXT: }
# CHECK-NEXT: ]
Check alignment in getSectionContentsAsArray. While the ArrayRef can technically have unaligned data, it would be extremely surprising if iterating over it caused undefined behavior when a reference to the underlying type was bound. llvm-svn: 319392
2017-11-30 01:44:22 +01:00
--- !ELF
FileHeader:
Class: ELFCLASS64
Data: ELFDATA2LSB
Type: ET_REL
Machine: EM_X86_64
Sections:
- Name: .foo
Type: SHT_PROGBITS
Content: 42
- Name: .rela.foo
Type: SHT_RELA
Info: .foo
Relocations:
[lib/ObjectYAML] - Make `ELFYAML::Relocation::Offset` optional. Currently `yaml2obj` require `Offset` field in a relocation description. There are many cases when `Offset` is insignificant in a context of a test case. Making `Offset` optional allows to simplify our test cases. This is what this patch does. Also, with this patch `obj2yaml` does not dump a zero offset of a relocation. Differential revision: https://reviews.llvm.org/D75608
2020-03-04 14:55:15 +01:00
- Type: R_X86_64_NONE
Reference in New Issue Copy Permalink