#
185b5b1d |
| 11-Nov-2014 |
David Majnemer <david.majnemer@gmail.com> |
llvm-objdump: Skip empty sections when dumping contents
Empty sections are just noise when using objdump. This is similar to what binutils does.
llvm-svn: 221680
|
#
80291274 |
| 08-Oct-2014 |
Rafael Espindola <rafael.espindola@gmail.com> |
Remove bogus std::error_code returns form SectionRef.
There are two methods in SectionRef that can fail:
* getName: The index into the string table can be invalid. * getContents: The section might
Remove bogus std::error_code returns form SectionRef.
There are two methods in SectionRef that can fail:
* getName: The index into the string table can be invalid. * getContents: The section might point to invalid contents.
Every other method will always succeed and returning and std::error_code just complicates the code. For example, a section can have an invalid alignment, but if we are able to get to the section structure at all and create a SectionRef, we will always be able to read that invalid alignment.
llvm-svn: 219314
show more ...
|
#
bf246f5a |
| 24-Sep-2014 |
Kevin Enderby <enderby@apple.com> |
Flush out enough of llvm-objdump’s SymbolizerSymbolLookUp() for Mach-O files to get the literal string “Hello world” printed as a comment on the instruction that loads the pointer to it. For now this
Flush out enough of llvm-objdump’s SymbolizerSymbolLookUp() for Mach-O files to get the literal string “Hello world” printed as a comment on the instruction that loads the pointer to it. For now this is just for x86_64. So for object files with relocation entries it produces things like:
leaq L_.str(%rip), %rax ## literal pool for: "Hello world\n"
and similar for fully linked images like executables:
leaq 0x4f(%rip), %rax ## literal pool for: "Hello world\n"
Also to allow testing against darwin’s otool(1), I hooked up the existing -no-show-raw-insn option to the Mach-O parser code, added the new Mach-O only -full-leading-addr option to match otool(1)'s printing of addresses and also added the new -print-imm-hex option.
llvm-svn: 218423
show more ...
|
#
56ebef45 |
| 16-Sep-2014 |
Nick Kledzik <kledzik@apple.com> |
[llvm-objdump] for mach-o add -bind, -lazy-bind, and -weak-bind options
This finishes the ability of llvm-objdump to print out all information from the LC_DYLD_INFO load command.
The -bind option p
[llvm-objdump] for mach-o add -bind, -lazy-bind, and -weak-bind options
This finishes the ability of llvm-objdump to print out all information from the LC_DYLD_INFO load command.
The -bind option prints out symbolic references that dyld must resolve immediately.
The -lazy-bind option prints out symbolc reference that are lazily resolved on first use.
The -weak-bind option prints out information about symbols which dyld must try to coalesce across images.
llvm-svn: 217853
show more ...
|
#
4d57159c |
| 15-Sep-2014 |
David Majnemer <david.majnemer@gmail.com> |
MC: Add support for BigObj
Teach WinCOFFObjectWriter how to write -mbig-obj style object files; these object files allow for more sections inside an object file.
Our support for BigObj is notably d
MC: Add support for BigObj
Teach WinCOFFObjectWriter how to write -mbig-obj style object files; these object files allow for more sections inside an object file.
Our support for BigObj is notably different from binutils and cl: we implicitly upgrade object files to BigObj instead of asking the user to compile the same file *again* but with another flag. This matches up with how LLVM treats ELF variants.
This was tested by forcing LLVM to always emit BigObj files and running the entire test suite. A specific test has also been added.
I've lowered the maximum number of sections in a normal COFF file, VS "14" CTP 3 supports no more than 65279 sections. This is important otherwise we might not switch to BigObj quickly enough, leaving us with a COFF file that we couldn't link.
yaml2obj support is all that remains to implement.
Differential Revision: http://reviews.llvm.org/D5349
llvm-svn: 217812
show more ...
|
#
ac43144e |
| 12-Sep-2014 |
Nick Kledzik <kledzik@apple.com> |
[llvm-objdump] support -rebase option for mach-o to dump rebasing info
Similar to my previous -exports-trie option, the -rebase option dumps info from the LC_DYLD_INFO load command. The rebasing inf
[llvm-objdump] support -rebase option for mach-o to dump rebasing info
Similar to my previous -exports-trie option, the -rebase option dumps info from the LC_DYLD_INFO load command. The rebasing info is a list of the the locations that dyld needs to adjust if a mach-o image is not loaded at its preferred address. Since ASLR is now the default, images almost never load at their preferred address, and thus need to be rebased by dyld.
llvm-svn: 217709
show more ...
|
#
44f51e51 |
| 10-Sep-2014 |
David Majnemer <david.majnemer@gmail.com> |
Object: Add support for bigobj
This adds support for reading the "bigobj" variant of COFF produced by cl's /bigobj and mingw's -mbig-obj.
The most significant difference that bigobj brings is more
Object: Add support for bigobj
This adds support for reading the "bigobj" variant of COFF produced by cl's /bigobj and mingw's -mbig-obj.
The most significant difference that bigobj brings is more than 2**16 sections to COFF.
bigobj brings a few interesting differences with it: - It doesn't have a Characteristics field in the file header. - It doesn't have a SizeOfOptionalHeader field in the file header (it's only used in executable files). - Auxiliary symbol records have the same width as a symbol table entry. Since symbol table entries are bigger, so are auxiliary symbol records.
Write support will come soon.
Differential Revision: http://reviews.llvm.org/D5259
llvm-svn: 217496
show more ...
|
#
888320e9 |
| 02-Sep-2014 |
Sean Silva <chisophugis@gmail.com> |
Nuke MCAnalysis.
The code is buggy and barely tested. It is also mostly boilerplate. (This includes MCObjectDisassembler, which is the interface to that functionality)
Following an IRC discussion w
Nuke MCAnalysis.
The code is buggy and barely tested. It is also mostly boilerplate. (This includes MCObjectDisassembler, which is the interface to that functionality)
Following an IRC discussion with Jim Grosbach, it seems sensible to just nuke the whole lot of functionality, and dig it up from VCS if necessary (I hope not!).
All of this stuff appears to have been added in a huge patch dump (look at the timeframe surrounding e.g. r182628) where almost every patch seemed to be untested and not reviewed before being committed. Post-review responses to the patches were never addressed. I don't think any of it would have passed pre-commit review.
I doubt anyone is depending on this, since this code appears to be extremely buggy. In limited testing that Michael Spencer and I did, we couldn't find a single real-world object file that wouldn't crash the CFG reconstruction stuff. The symbolizer stuff has O(n^2) behavior and so is not much use to anyone anyway. It seemed simpler to remove them as a whole. Most of this code is boilerplate, which is the only way it was able to scrape by 60% coverage.
HEADSUP: Modules folks, some files I nuked were referenced from include/llvm/module.modulemap; I just deleted the references. Hopefully that is the right fix (one was a FIXME though!).
llvm-svn: 216983
show more ...
|
Revision tags: llvmorg-3.5.0 |
|
#
d04bc358 |
| 30-Aug-2014 |
Nick Kledzik <kledzik@apple.com> |
Object/llvm-objdump: allow dumping of mach-o exports trie
MachOObjectFile in lib/Object currently has no support for parsing the rebase, binding, and export information from the LC_DYLD_INFO load c
Object/llvm-objdump: allow dumping of mach-o exports trie
MachOObjectFile in lib/Object currently has no support for parsing the rebase, binding, and export information from the LC_DYLD_INFO load command in final linked mach-o images. This patch adds support for parsing the exports trie data structure. It also adds an option to llvm-objdump to dump that export info.
I did the exports parsing first because it is the hardest. The information is encoded in a trie structure, but the standard ObjectFile way to inspect content is through iterators. So I needed to make an iterator that would do a non-recursive walk through the trie and maintain the concatenation of edges needed for the current string prefix.
I plan to add similar support in MachOObjectFile and llvm-objdump to parse/display the rebasing and binding info too.
llvm-svn: 216808
show more ...
|
Revision tags: llvmorg-3.5.0-rc4 |
|
#
3fd1e993 |
| 25-Aug-2014 |
Rafael Espindola <rafael.espindola@gmail.com> |
Modernize raw_fd_ostream's constructor a bit.
Take a StringRef instead of a "const char *". Take a "std::error_code &" instead of a "std::string &" for error.
A create static method would be even b
Modernize raw_fd_ostream's constructor a bit.
Take a StringRef instead of a "const char *". Take a "std::error_code &" instead of a "std::string &" for error.
A create static method would be even better, but this patch is already a bit too big.
llvm-svn: 216393
show more ...
|
#
b76d386d |
| 22-Aug-2014 |
Kevin Enderby <enderby@apple.com> |
Add the start of the support for llvm-objdump’s -private-headers for Mach-O files.
This adds the printing of the mach header. Load command printing will be next.
llvm-svn: 216285
|
Revision tags: llvmorg-3.5.0-rc3 |
|
#
48af1c2a |
| 19-Aug-2014 |
Rafael Espindola <rafael.espindola@gmail.com> |
Don't own the buffer in object::Binary.
Owning the buffer is somewhat inflexible. Some Binaries have sub Binaries (like Archive) and we had to create dummy buffers just to handle that. It is also a
Don't own the buffer in object::Binary.
Owning the buffer is somewhat inflexible. Some Binaries have sub Binaries (like Archive) and we had to create dummy buffers just to handle that. It is also a bad fit for IRObjectFile where the Module wants to own the buffer too.
Keeping this ownership would make supporting IR inside native objects particularly painful.
This patch focuses in lib/Object. If something elsewhere used to own an Binary, now it also owns a MemoryBuffer.
This patch introduces a few new types.
* MemoryBufferRef. This is just a pair of StringRefs for the data and name. This is to MemoryBuffer as StringRef is to std::string. * OwningBinary. A combination of Binary and a MemoryBuffer. This is needed for convenience functions that take a filename and return both the buffer and the Binary using that buffer.
The C api now uses OwningBinary to avoid any change in semantics. I will start a new thread to see if we want to change it and how.
llvm-svn: 216002
show more ...
|
#
c66d761b |
| 17-Aug-2014 |
Rafael Espindola <rafael.espindola@gmail.com> |
llvm-objdump: don't print relocations in non-relocatable files.
This matches the behavior of GNU objdump.
llvm-svn: 215844
|
#
e45c7403 |
| 17-Aug-2014 |
Rafael Espindola <rafael.espindola@gmail.com> |
Fix an off-by-one bug in the target independent llvm-objdump.
It would prevent the display of a single byte instruction before a label.
Patch by Steve King!
llvm-svn: 215837
|
Revision tags: llvmorg-3.5.0-rc2 |
|
#
c9595620 |
| 06-Aug-2014 |
Kevin Enderby <enderby@apple.com> |
Add the -mcpu= option to llvm-objdump for use with the disassemblers. Also make the disassembler created with the Mach-O parser (the -m option) pick up the Target specific attributes specified with -
Add the -mcpu= option to llvm-objdump for use with the disassemblers. Also make the disassembler created with the Mach-O parser (the -m option) pick up the Target specific attributes specified with -mattr option.
llvm-svn: 215032
show more ...
|
#
3f6481d0 |
| 01-Aug-2014 |
Rafael Espindola <rafael.espindola@gmail.com> |
Remove some calls to std::move.
Instead of moving out the data in a ErrorOr<std::unique_ptr<Foo>>, get a reference to it.
Thanks to David Blaikie for the suggestion.
llvm-svn: 214516
|
#
4bd286ab |
| 01-Aug-2014 |
Tim Northover <tnorthover@apple.com> |
llvm-objdump: implement printing for MachO __compact_unwind info.
llvm-svn: 214509
|
#
3f0549f6 |
| 31-Jul-2014 |
Rafael Espindola <rafael.espindola@gmail.com> |
Move MCObjectSymbolizer.h to MC/MCAnalysis.
The cpp file is already in lib/MC/MCAnalysis.
llvm-svn: 214424
|
#
437b0d58 |
| 31-Jul-2014 |
Rafael Espindola <rafael.espindola@gmail.com> |
Use std::unique_ptr to make the ownership explicit.
llvm-svn: 214377
|
Revision tags: llvmorg-3.5.0-rc1 |
|
#
8f6b04cb |
| 14-Jul-2014 |
David Majnemer <david.majnemer@gmail.com> |
llvm-objdump: Handle BSS sections larger than the object file
The size of the uninitialized sections, like BSS, can exceed the size of the object file.
Do not attempt to grab the contents of such s
llvm-objdump: Handle BSS sections larger than the object file
The size of the uninitialized sections, like BSS, can exceed the size of the object file.
Do not attempt to grab the contents of such sections.
llvm-svn: 212953
show more ...
|
#
cbc5ac7a |
| 02-Jul-2014 |
Rafael Espindola <rafael.espindola@gmail.com> |
Move CFG building code to a new lib/MC/MCAnalysis library.
The new library is 150KB on a Release+Asserts build, so it is quiet a bit of code that regular users of MC don't need to link with now.
ll
Move CFG building code to a new lib/MC/MCAnalysis library.
The new library is 150KB on a Release+Asserts build, so it is quiet a bit of code that regular users of MC don't need to link with now.
llvm-svn: 212209
show more ...
|
#
e69170a1 |
| 26-Jun-2014 |
Alp Toker <alp@nuanti.com> |
Revert "Introduce a string_ostream string builder facilty"
Temporarily back out commits r211749, r211752 and r211754.
llvm-svn: 211814
|
#
61471738 |
| 26-Jun-2014 |
Alp Toker <alp@nuanti.com> |
Introduce a string_ostream string builder facilty
string_ostream is a safe and efficient string builder that combines opaque stack storage with a built-in ostream interface.
small_string_ostream<by
Introduce a string_ostream string builder facilty
string_ostream is a safe and efficient string builder that combines opaque stack storage with a built-in ostream interface.
small_string_ostream<bytes> additionally permits an explicit stack storage size other than the default 128 bytes to be provided. Beyond that, storage is transferred to the heap.
This convenient class can be used in most places an std::string+raw_string_ostream pair or SmallString<>+raw_svector_ostream pair would previously have been used, in order to guarantee consistent access without byte truncation.
The patch also converts much of LLVM to use the new facility. These changes include several probable bug fixes for truncated output, a programming error that's no longer possible with the new interface.
llvm-svn: 211749
show more ...
|
#
ae460027 |
| 16-Jun-2014 |
Rafael Espindola <rafael.espindola@gmail.com> |
Convert the Archive API to use ErrorOr.
Now that we have c++11, even things like ErrorOr<std::unique_ptr<...>> are easy to use.
No intended functionality change.
llvm-svn: 211033
|
#
4453e429 |
| 13-Jun-2014 |
Rafael Espindola <rafael.espindola@gmail.com> |
Remove 'using std::error_code' from tools.
llvm-svn: 210876
|