| Commit message (Collapse) | Author | Age | Files | Lines | 
| | 
| 
| 
|  | 
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
 | 
| | 
| 
| 
|  | 
llvm-svn: 184268
 | 
| | 
| 
| 
|  | 
llvm-svn: 184263
 | 
| | 
| 
| 
| 
| 
|  | 
Currently, we only output the name.
llvm-svn: 184255
 | 
| | 
| 
| 
|  | 
llvm-svn: 184022
 | 
| | 
| 
| 
| 
| 
| 
|  | 
For consistency, change the address in the test case from 0xDEADBEEF to
0xCAFEBABE since 0xCAFEBABE that actually has a 2-byte alignment.
llvm-svn: 183962
 | 
| | 
| 
| 
|  | 
llvm-svn: 183955
 | 
| | 
| 
| 
|  | 
llvm-svn: 183954
 | 
| | 
| 
| 
| 
| 
| 
|  | 
The current functionality is extremely basic and a bit rough around the
edges, but it will flesh out in future commits.
llvm-svn: 183953
 | 
| | 
| 
| 
| 
| 
|  | 
This slipped in during a hasty renaming.
llvm-svn: 183810
 | 
| | 
| 
| 
| 
| 
|  | 
Should bring bots back to life.
llvm-svn: 183715
 | 
|   
  
  
  
  
  
  
  
   | 
Currently, only emitting the ELF header is supported (no sections or
segments).
The ELFYAML code organization is broadly similar to the COFFYAML code.
llvm-svn: 183711
 |