This makes the buffer ownership on error conditions very natural. The buffer
is only moved out of the argument if an object is constructed that now
owns the buffer.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211546 91177308-0d34-0410-b5e6-96231b3b80d8
This allows us to just use a std::unique_ptr to store the pointer to the buffer.
The flip side is that they have to support releasing the buffer back to the
caller.
Overall this looks like a more efficient and less brittle api.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211542 91177308-0d34-0410-b5e6-96231b3b80d8
fat files) to print “ (for architecture XYZ)” for fat files with more than
one architecture to be like what the darwin tools do for fat files.
Also clean up the Mach-O printing of archive membernames in llvm-nm to use
the darwin form of "libx.a(foo.o)".
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211316 91177308-0d34-0410-b5e6-96231b3b80d8
fat files containing archives.
Also fix a bug in MachOUniversalBinary::ObjectForArch::ObjectForArch()
where it needed a >= when comparing the Index with the number of
objects in a fat file. As the index starts at 0.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211230 91177308-0d34-0410-b5e6-96231b3b80d8
The main point of this class is to provide a cheap object interface to a bitcode
file, so it has to be as lazy as possible.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211207 91177308-0d34-0410-b5e6-96231b3b80d8
This makes llvm-nm ignore members that are not sufficiently aligned for
lib/Object to handle.
These archives are invalid. GNU AR is able to handle this, but in general
just warns about broken archive members.
We should probably start warning too, but for now just make sure llvm-nm
exits with an 0.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211036 91177308-0d34-0410-b5e6-96231b3b80d8
Now that we have c++11, even things like ErrorOr<std::unique_ptr<...>> are
easy to use.
No intended functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211033 91177308-0d34-0410-b5e6-96231b3b80d8
This code was never being used and any use of it would look fairly strange.
For example, it would try to map a object_error::parse_failed to
std::errc::invalid_argument.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210912 91177308-0d34-0410-b5e6-96231b3b80d8
This is a minimal change to remove the header. I will remove the occurrences
of "using std::error_code" in a followup patch.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210803 91177308-0d34-0410-b5e6-96231b3b80d8
The idea of this patch is to turn llvm/Support/system_error.h into a
transitional header that just brings in the erorr_code api to the llvm
namespace. I will remove it shortly afterwards.
The cases where the general idea needed some tweaking:
* std::errc is a namespace in msvc, so we cannot use "using std::errc". I could
add an #ifdef, but there were not that many uses, so I just added std:: to
them in this patch.
* Template specialization had to be moved to the std namespace in this
patch set already.
* The msvc implementation of default_error_condition doesn't seem to
provide the same transformations as we need. Not too surprising since
the standard doesn't actually say what "equivalent" means. I fixed the
problem by keeping our old mapping and using it at error_code
construction time.
Despite these shortcomings I think this is still a good thing. Some reasons:
* The different implementations of system_error might improve over time.
* It removes 925 lines of code from llvm already.
* It removes 6313 bytes from the text segment of the clang binary when
it is built with gcc and 2816 bytes when building with clang and
libstdc++.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210687 91177308-0d34-0410-b5e6-96231b3b80d8
This is a first step in seeing if it is possible to make llvm-nm produce
the same output as darwin's nm(1). Darwin's default format is bsd but its
-m output prints the longer Mach-O specific details. For now I added the
"-format darwin" to do this (whos name may need to change in the future).
As there are other Mach-O specific flags to nm(1) which I'm hoping to add some
how in the future. But I wanted to see if I could get the correct output for
-m flag using llvm-nm and the libObject interfaces.
I got this working but would love to hear what others think about this approach
to getting object/format specific details printed with llvm-nm.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210285 91177308-0d34-0410-b5e6-96231b3b80d8
There is no std::error_code::success, so this removes much of the noise
in transitioning to std::error_code.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209952 91177308-0d34-0410-b5e6-96231b3b80d8
This makes LLVM create N_INDR aliases (to be resolved by the linker) when
appropriate.
rdar://problem/15125513
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209894 91177308-0d34-0410-b5e6-96231b3b80d8
field represents ELF section header sh_info field and does not have any
sense for regular sections. Its interpretation depends on section type.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209801 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209504 91177308-0d34-0410-b5e6-96231b3b80d8
for undefined symbols, so it matches what COFFObjectFile::getSymbolAddress
does. This allows llvm-nm to print spaces instead of 0’s for the value
of undefined symbols in Mach-O files.
To make this change other uses of MachOObjectFile::getSymbolAddress
are updated to handle when the Value is returned as UnknownAddressOrSize.
Which is needed to keep two of the ExecutionEngine tests working for example.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209253 91177308-0d34-0410-b5e6-96231b3b80d8
for undefined symbols. Allowing llvm-nm to print spaces instead of 0’s for
the value of undefined symbols in Mach-O files.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209235 91177308-0d34-0410-b5e6-96231b3b80d8
so that llvm-size will total up all the sections in the Berkeley format. This
allows for rough categorizations for Mach-O sections. And allows the total of
llvm-size’s Berkeley and System V formats to be the same.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209158 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208995 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208752 91177308-0d34-0410-b5e6-96231b3b80d8
SECTDIFF relocations on 32-bit x86.
This fixes several of the MCJIT regression test failures that show up on 32-bit
builds.
<rdar://problem/16886294>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208635 91177308-0d34-0410-b5e6-96231b3b80d8
which are corresponding to the current target read from the ELF file.
This fix cannot be tested until obj2yaml does not support ELF format.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207905 91177308-0d34-0410-b5e6-96231b3b80d8
We already do this for shstrtab, so might as well do it for strtab. This
extracts the string table building code into a separate class. The idea
is to use it for other object formats too.
I mostly wanted to do this for the general principle, but it does save a
little bit on object file size. I tried this on a clang bootstrap and
saved 0.54% on the sum of object file sizes (1.14 MB out of 212 MB for
a release build).
Differential Revision: http://reviews.llvm.org/D3533
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207670 91177308-0d34-0410-b5e6-96231b3b80d8
We normally don't drop functions from the C API's, but in this case I think we
can:
* The old implementation of getFileOffset was fairly broken
* The introduction of LLVMGetSymbolFileOffset was itself a C api breaking
change as it removed LLVMGetSymbolOffset.
* It is an incredibly specialized use case. The only reason MCJIT needs it is
because of its odd position of being a dynamic linker of .o files.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206750 91177308-0d34-0410-b5e6-96231b3b80d8
