| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 186029
|
|
|
|
| |
llvm-svn: 185937
|
|
|
|
| |
llvm-svn: 185936
|
|
|
|
| |
llvm-svn: 185933
|
|
|
|
|
|
|
| |
It is always computed the same way (by parsing the header). Doing it in the
constructor simplifies the callers a bit.
llvm-svn: 185905
|
|
|
|
| |
llvm-svn: 185901
|
|
|
|
|
|
|
| |
Previously, it would simply output nothing, but it should output an
empty string `""`.
llvm-svn: 185894
|
|
|
|
| |
llvm-svn: 185709
|
|
|
|
|
|
|
| |
This a bit more efficient and avoids having a function that uses the string
table being called by a function that searches for it.
llvm-svn: 185680
|
|
|
|
| |
llvm-svn: 185664
|
|
|
|
|
|
| |
While there, use early returns to reduce nesting.
llvm-svn: 185547
|
|
|
|
|
|
| |
macho_dsym_companion case.
llvm-svn: 185139
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
std::string instead.
llvm-svn: 184291
|
|
|
|
| |
llvm-svn: 184268
|
|
|
|
| |
llvm-svn: 184263
|
|
|
|
|
|
| |
Currently, we only output the name.
llvm-svn: 184255
|
|
|
|
| |
llvm-svn: 184191
|
|
|
|
|
|
|
| |
This allows the compiler to see the enum and warn about it. While in here,
fix a switch to not use a default and fix style violations.
llvm-svn: 184186
|
|
|
|
| |
llvm-svn: 184022
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Archive files (.a) can have a symbol table indicating which object
files in them define which symbols. The purpose of this symbol table
is to speed up linking by allowing the linker the read only the .o
files it is actually going to use instead of having to parse every
object's symbol table.
LLVM's archive library currently supports a LLVM specific format for
such table. It is hard to see any value in that now that llvm-ld is
gone:
* System linkers don't use it: GNU ar uses the same plugin as the
linker to create archive files with a regular index. The OS X ar
creates no symbol table for IL files, I assume the linker just parses
all IL files.
* It doesn't interact well with archives having both IL and native objects.
* We probably don't want to be responsible for yet another archive
format variant.
This patch then:
* Removes support for creating and reading such index from lib/Archive.
* Remove llvm-ranlib, since there is nothing left for it to do.
We should in the future add support for regular indexes to llvm-ar for
both native and IL objects. When we do that, llvm-ranlib should be
reimplemented as a symlink to llvm-ar, as it is equivalent to "ar s".
llvm-svn: 184019
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
These records are mandatory for executables and are used by the loader.
Reviewers: rafael
CC: llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D939
llvm-svn: 183852
|
|
|
|
|
|
| |
This slipped in during a hasty renaming.
llvm-svn: 183810
|
|
|
|
|
|
|
| |
This enables the compiler to see the enum and produce warnings about a switch
not being fully covered. Fix one of these warnings.
llvm-svn: 183749
|
|
|
|
|
|
| |
No functionality change.
llvm-svn: 183747
|
|
|
|
|
|
| |
No functionality change.
llvm-svn: 183745
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 183669
|
|
|
|
|
|
|
|
| |
sys::IdentifyFileType is already conscious of the length, and
object_error::invalid_file_type is returned below anyway if
sys::IdentifyFileType doesn't recognize the file.
llvm-svn: 183605
|
|
|
|
|
|
| |
Thanks to Benjamin Kramer for the suggestion.
llvm-svn: 183540
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
from the LC_DATA_IN_CODE load command. And when disassembling print
the data in code formatted for the kind of data it and not disassemble those
bytes.
I added the format specific functionality to the derived class MachOObjectFile
since these tables only appears in Mach-O object files. This is my first
attempt to modify the libObject stuff so if folks have better suggestions
how to fit this in or suggestions on the implementation please let me know.
rdar://11791371
llvm-svn: 183424
|
|
|
|
| |
llvm-svn: 183403
|
|
|
|
|
|
|
| |
This hides the implementation. A future commit will remove the
error-prone getHex() and getBinary() methods.
llvm-svn: 183352
|
|
|
|
|
|
| |
And add a doxygen comment.
llvm-svn: 183350
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, yaml2coff.cpp had a writeHexData static helper function to
do this, but it is generally useful functionality.
Also, validate hex strings up-front to avoid running having to handle
errors "deep inside" the yaml2obj code (it also gives better diagnostics
than it used to).
llvm-svn: 183345
|
|
|
|
| |
llvm-svn: 183293
|
|
|
|
|
|
| |
It will be used for ELF dumping too.
llvm-svn: 183287
|
|
|
|
|
|
|
|
| |
In ELF (as in MachO), not all relocations point to symbols. Represent this
properly by using a symbol_iterator instead of a SymbolRef. Update llvm-readobj
ELF's dumper to handle relocatios without symbols.
llvm-svn: 183284
|
|
|
|
| |
llvm-svn: 183091
|
|
|
|
| |
llvm-svn: 183042
|
|
|
|
| |
llvm-svn: 183040
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For COFF and MachO, sections semantically have relocations that apply to them.
That is not the case on ELF.
In relocatable objects (.o), a section with relocations in ELF has offsets to
another section where the relocations should be applied.
In dynamic objects and executables, relocations don't have an offset, they have
a virtual address. The section sh_info may or may not point to another section,
but that is not actually used for resolving the relocations.
This patch exposes that in the ObjectFile API. It has the following advantages:
* Most (all?) clients can handle this more efficiently. They will normally walk
all relocations, so doing an effort to iterate in a particular order doesn't
save time.
* llvm-readobj now prints relocations in the same way the native readelf does.
* probably most important, relocations that don't point to any section are now
visible. This is the case of relocations in the rela.dyn section. See the
updated relocation-executable.test for example.
llvm-svn: 182908
|