| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
It is only ever used by obj2yaml and yaml2obj. No point in linking it
everywhere.
llvm-svn: 262368
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some architecture specific ELF section flags might have the same value
(for example SHF_X86_64_LARGE and SHF_HEX_GPREL) and we have to check
machine architectures to select an appropriate set of possible flags.
The patch selects architecture specific flags into separate arrays
`ElfxxxSectionFlags` and combines `ElfSectionFlags` and `ElfxxxSectionFlags`
before pass to the `StreamWriter::printFlags()` method.
Differential Revision: http://reviews.llvm.org/D16269
llvm-svn: 258334
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: silvas
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D14444
llvm-svn: 253052
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D14109
llvm-svn: 252043
|
|
|
|
|
|
|
|
| |
Also adds a 'trivial' ELF file. This was generated by assembling
and linking a file with the symbol main which contains a single
return instruction.
llvm-svn: 251096
|
|
|
|
|
|
|
|
| |
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D11263
llvm-svn: 243724
|
|
|
|
|
|
|
|
|
|
| |
SHT_NOBITS sections do not have content in an object file. Now the yaml2obj
tool does not accept `Content` field for such sections, and the obj2yaml
tool does not attempt to read the section content from a file.
Restore r241350 and r241352.
llvm-svn: 241377
|
|
|
|
|
|
|
|
|
|
|
| |
r241350 broke lld tests.
r241352 depends on r241350.
Original messages:
"[ELFYAML] Fix handling SHT_NOBITS sections by obj2yaml/yaml2obj tools"
"[ELFYAML] Make the Size field for .bss section optional"
llvm-svn: 241354
|
|
|
|
|
|
| |
It's a common case to have a zero-size .bss section in an object file.
llvm-svn: 241352
|
|
|
|
|
|
|
|
| |
SHT_NOBITS sections do not have content in an object file. Now yaml2obj
tool does not accept `Content` field for such sections, and obj2yaml
tool does not attempt to read the section content from a file.
llvm-svn: 241350
|
|
|
|
|
|
| |
Apparently, the style needs to be agreed upon first.
llvm-svn: 240390
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The patch is generated using this command:
tools/clang/tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \
-checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \
llvm/lib/
Thanks to Eugene Kosov for the original patch!
llvm-svn: 240137
|
|
|
|
|
|
| |
Sorry, I have no idea how grep failed to find this.
llvm-svn: 240133
|
|
|
|
| |
llvm-svn: 236807
|
|
|
|
|
|
|
| |
This change adds support for the SHT_MIPS_ABIFLAGS section
reading/writing to the obj2yaml and yaml2obj tools.
llvm-svn: 236738
|
|
|
|
| |
llvm-svn: 236728
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
CloudABI is a POSIX-like runtime environment built around the concept of
capability-based security. More details:
https://github.com/NuxiNL/cloudlibc
CloudABI uses its own ELFOSABI number. This number has been allocated by
the maintainers of ELF a couple of days ago.
Reviewed by: echristo
llvm-svn: 231681
|
|
|
|
|
|
| |
This adds section group support to the tools obj2yaml and yaml2obj.
llvm-svn: 230124
|
|
|
|
|
|
| |
Follow up to r227318.
llvm-svn: 227422
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
MIPS64 ELF file has a very specific relocation record format. Each
record might specify up to three relocation operations. So the `r_info`
field in fact consists of three relocation type sub-fields and optional
code of "special" symbols.
http://techpubs.sgi.com/library/manuals/4000/007-4658-001/pdf/007-4658-001.pdf
page 40
The patch implements support of the MIPS64 relocation record format in
yaml2obj/obj2yaml tools by introducing new optional Relocation fields:
Type2, Type3, and SpecSym. These fields are recognized only if the
object/YAML file relates to the MIPS64 target.
Differential Revision: http://reviews.llvm.org/D7136
llvm-svn: 227044
|
|
|
|
| |
llvm-svn: 226943
|
|
|
|
|
|
| |
Tested with check-all with no regressions.
llvm-svn: 223112
|
|
|
|
|
|
|
|
|
|
| |
We can now use the ELF relocation .def files to create the mapping
of relocation numbers to names and avoid having to duplicate the
list of relocations.
Patch by Will Newton.
llvm-svn: 222567
|
|
|
|
|
|
|
| |
Patch by Daniel Stewart <stewartd@codeaurora.org>!
Phabricator Revision: http://reviews.llvm.org/D6192
llvm-svn: 221639
|
|
|
|
|
|
|
|
| |
The ELF symbol `st_other` field might contain additional flags besides
visibility ones. This patch implements support for some MIPS specific
flags.
llvm-svn: 221491
|
|
|
|
| |
llvm-svn: 221268
|
|
|
|
| |
llvm-svn: 212910
|
|
|
|
|
|
| |
obj2yaml and yaml2obj tools.
llvm-svn: 212908
|
|
|
|
|
|
| |
Recognize only flags which correspond to the current target.
llvm-svn: 212880
|
|
|
|
|
|
| |
(default/hidden/protected).
llvm-svn: 210316
|
|
|
|
|
|
|
| |
field represents ELF section header sh_info field and does not have any
sense for regular sections. Its interpretation depends on section type.
llvm-svn: 209801
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some bit-set fields used in ELF file headers in fact contain two parts.
The first one is a regular bit-field. The second one is an enumeraion.
For example ELF header `e_flags` for MIPS target might contain the
following values:
Bit-set values:
EF_MIPS_NOREORDER = 0x00000001
EF_MIPS_PIC = 0x00000002
EF_MIPS_CPIC = 0x00000004
EF_MIPS_ABI2 = 0x00000020
Enumeration:
EF_MIPS_ARCH_32 = 0x50000000
EF_MIPS_ARCH_64 = 0x60000000
EF_MIPS_ARCH_32R2 = 0x70000000
EF_MIPS_ARCH_64R2 = 0x80000000
For printing bit-sets we use the `yaml::IO::bitSetCase()`. It does not
support bit-set/enumeration combinations and prints too many flags from
an enumeration part. This patch fixes this problem. New method
`yaml::IO::maskedBitSetCase()` handle "enumeration" part of bitset
defined by provided mask.
Patch reviewed by Nick Kledzik and Sean Silva.
llvm-svn: 209504
|
|
|
|
| |
llvm-svn: 209201
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now the only method to configure ELF section's content and size is to assign
a hexadecimal string to the `Content` field. Unfortunately this way is
completely useless when you need to declare a really large section.
To solve this problem this patch adds one more optional field `Size`
to the `RawContentSection` structure. When yaml2obj generates an ELF file
it uses the following algorithm:
1. If both `Content` and `Size` fields are missed create an empty section.
2. If only `Content` field is missed take section length from the `Size`
field and fill the section by zero.
3. If only `Size` field is missed create a section using data from
the `Content` field.
4. If both `Content` and `Size` fields are provided validate that the `Size`
value is not less than size of `Content` data. Than take section length
from the `Size`, fill beginning of the section by `Content` and the rest
by zero.
Examples
--------
* Create a section 0x10000 bytes long filled by zero
Name: .data
Type: SHT_PROGBITS
Flags: [ SHF_ALLOC ]
Size: 0x10000
* Create a section 0x10000 bytes long starting from 'CA' 'FE' 'BA' 'BE'
Name: .data
Type: SHT_PROGBITS
Flags: [ SHF_ALLOC ]
Content: CAFEBABE
Size: 0x10000
The patch reviewed by Michael Spencer.
llvm-svn: 208995
|
|
|
|
| |
llvm-svn: 208905
|
|
|
|
|
|
|
|
|
|
| |
The ELF header e_flags field in the MIPS related test cases handled
incorrectly. The obj2yaml prints too many flags. I will fix that in the
next patches.
The patch reviewed by Michael Spencer and Sean Silva.
llvm-svn: 208752
|
|
|
|
| |
llvm-svn: 208228
|
|
|
|
|
|
|
|
| |
which are corresponding to the current target read from the ELF file.
This fix cannot be tested until obj2yaml does not support ELF format.
llvm-svn: 207905
|
|
|
|
| |
llvm-svn: 207904
|
|
|
|
|
|
| |
necessary.
llvm-svn: 207593
|
|
|
|
|
|
| |
colons.
llvm-svn: 207003
|
|
|
|
|
|
| |
to prevent memory leaks.
llvm-svn: 206969
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The patch implements support for both relocation record formats: Elf_Rel
and Elf_Rela. It is possible to define relocation against symbol only.
Relocations against sections will be implemented later. Now yaml2obj
recognizes X86_64, MIPS and Hexagon relocation types.
Example of relocation section specification:
Sections:
- Name: .text
Type: SHT_PROGBITS
Content: "0000000000000000"
AddressAlign: 16
Flags: [SHF_ALLOC]
- Name: .rel.text
Type: SHT_REL
Info: .text
AddressAlign: 4
Relocations:
- Offset: 0x1
Symbol: glob1
Type: R_MIPS_32
- Offset: 0x2
Symbol: glob2
Type: R_MIPS_CALL16
The patch reviewed by Michael Spencer, Sean Silva, Shankar Easwaran.
llvm-svn: 206017
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The FileHeader mapping now accepts an optional Flags sequence that accepts
the EF_<arch>_<flag> constants. When not given, Flags defaults to zero.
Reviewers: atanasyan
Reviewed By: atanasyan
CC: llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D3213
llvm-svn: 205173
|
|
|
|
| |
llvm-svn: 190769
|
|
|
|
|
|
| |
Approval in here http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-July/064169.html
llvm-svn: 187145
|
|
|
|
|
|
|
|
|
| |
Although in reality the symbol table in ELF resides in a section, the
standard requires that there be no more than one SHT_SYMTAB. To enforce
this constraint, it is cleaner to group all the symbols under a
top-level `Symbols` key on the object file.
llvm-svn: 184627
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead, just have 3 sub-lists, one for each of
{STB_LOCAL,STB_GLOBAL,STB_WEAK}.
This allows us to be a lot more explicit w.r.t. the symbol ordering in
the object file, because if we allowed explicitly setting the STB_*
`Binding` key for the symbol, then we might have ended up having to
shuffle STB_LOCAL symbols to the front of the list, which is likely to
cause confusion and potential for error.
Also, this new approach is simpler ;)
llvm-svn: 184506
|
|
|
|
|
|
|
|
|
| |
After this patch, the ELF file produced by
`yaml2obj-elf-symbol-basic.yaml`, when linked and executed on x86_64
(under SysV ABI, obviously; I tested on Linux), produces a working
executable that goes into an infinite loop!
llvm-svn: 184469
|
|
|
|
| |
llvm-svn: 184468
|