Make the use of the cache more transparent to the users. There is no reason
that the cached entries really need to be passed along. The overhead for doing
so is minimal: a single extra parameter. This requires that some standalone
functions be brought into the COFFDumper class so that they may access the
cache.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209604 91177308-0d34-0410-b5e6-96231b3b80d8
Switch to use references for parameters that are guaranteed to be non-null.
Simplifies the code a slight bit in preparation for another change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209603 91177308-0d34-0410-b5e6-96231b3b80d8
If a filename is a multiple of 18 characters, there will be no null-terminator.
This will result in an invalid access by the constructed StringRef. Add a test
case to exercise this and fix that handling. Address this same vulnerability in
llvm-readobj as well.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206145 91177308-0d34-0410-b5e6-96231b3b80d8
We need .symtab_shndxr if and only if a symbol references a section with an
index >= 0xff00.
The old code was trying to figure out if the section was needed ahead of time,
making it a fairly dependent on the code actually writing the table. It was
also somewhat conservative and would create the section in cases where it was
not needed.
If I remember correctly, the old structure was there so that the sections were
created in the same order gas creates them. That was valuable when MC's support
for ELF was new and we tested with elf-dump.py.
This patch refactors the symbol table creation to another class and makes it
obvious that .symtab_shndxr is really only created when we are about to output
a reference to a section index >= 0xff00.
While here, also improve the tests to use macros. One file is one section
short of needing .symtab_shndxr, the second one has just the right number.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@204769 91177308-0d34-0410-b5e6-96231b3b80d8
The current state of affairs has auxiliary symbols described as a big
bag of bytes. This is less than satisfying, it detracts from the YAML
file as being human readable.
Instead, allow for symbols to optionally contain their auxiliary data.
This allows us to have a much higher level way of describing things like
weak symbols, function definitions and section definitions.
This depends on D3105.
Differential Revision: http://llvm-reviews.chandlerc.com/D3092
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@204214 91177308-0d34-0410-b5e6-96231b3b80d8
Since our error_category is based on the std one, we should have the
same visibility for the constructor. This also allows us to avoid
using the _do_message implementation detail in our own categories.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203998 91177308-0d34-0410-b5e6-96231b3b80d8
The official specifications state the name to be ARMNT (as per the Microsoft
Portable Executable and Common Object Format Specification v8.3).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203530 91177308-0d34-0410-b5e6-96231b3b80d8
This compiles with no changes to clang/lld/lldb with MSVC and includes
overloads to various functions which are used by those projects and llvm
which have OwningPtr's as parameters. This should allow out of tree
projects some time to move. There are also no changes to libs/Target,
which should help out of tree targets have time to move, if necessary.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203083 91177308-0d34-0410-b5e6-96231b3b80d8
In some cases it is possible to have a personality 0 unwinding opcodes in the
extab (such as when .handlerdata is used in the assembly). Simply decode the 3
opcodes for that case.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201030 91177308-0d34-0410-b5e6-96231b3b80d8
utohexstr provides a temporary string, making it unsafe to use with the Twine
interface which will not copy the string. Switch to using std::string.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200457 91177308-0d34-0410-b5e6-96231b3b80d8
This is acceptted by clang and gcc, but MSVC seems to balk at it. As it is
unneeded, simply drop it. Fixes MSVC buildbots.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200456 91177308-0d34-0410-b5e6-96231b3b80d8
exp2 is not available on Windows. Fortunately, we are calculating powers of 2
with expontents within the range of [4,12]. Simply use an equivalent bitshift
operation to repair compilation with MSVC which does not provide this standard
function.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200454 91177308-0d34-0410-b5e6-96231b3b80d8
Enhance the ARM specific parsing support in llvm-readobj to support attributes.
This allows for simpler tests to validate encoding of the build attributes as
specified in the ARM ELF specification.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200450 91177308-0d34-0410-b5e6-96231b3b80d8
None of the object file formats reported error on iterator increment. In
retrospect, that is not too surprising: no object format stores symbols or
sections in a linked list or other structure that requires chasing pointers.
As a consequence, all error checking can be done on begin() and end().
This reduces the text segment of bin/llvm-readobj in my machine from 521233 to
518526 bytes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200442 91177308-0d34-0410-b5e6-96231b3b80d8
editbin.exe and link.exe both accepts /highentropyva option to set this bit, so
doing s/VIRTUAL_ADDRESS/VA/ should make sense.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200191 91177308-0d34-0410-b5e6-96231b3b80d8
That bit is not documented in the PE/COFF spec published by Microsoft, so we
don't know the official name of it. I named this bit
IMAGE_DLL_CHARACTERISTICS_HIGH_ENTROPY_VIRTUAL_ADDRESS because the bit is
reported as "high entropy virtual address" by dumpbin.exe,
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200121 91177308-0d34-0410-b5e6-96231b3b80d8
PE32+ supports 64 bit address space, but the file format remains 32 bit.
So its file format is pretty similar to PE32 (32 bit executable). The
differences compared to PE32 are (1) the lack of "BaseOfData" field and
(2) some of its data members are 64 bit.
In this patch, I added a new member function to get a PE32+ Header object to
COFFObjectFile class and made llvm-readobj to use it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200117 91177308-0d34-0410-b5e6-96231b3b80d8
