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
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
This patch changes GlobalAlias to point to an arbitrary ConstantExpr and it is
up to MC (or the system assembler) to decide if that expression is valid or not.
This reduces our ability to diagnose invalid uses and how early we can spot
them, but it also lets us do things like
@test5 = alias inttoptr(i32 sub (i32 ptrtoint (i32* @test2 to i32),
i32 ptrtoint (i32* @bar to i32)) to i32*)
An important implication of this patch is that the notion of aliased global
doesn't exist any more. The alias has to encode the information needed to
access it in its metadata (linkage, visibility, type, etc).
Another consequence to notice is that getSection has to return a "const char *".
It could return a NullTerminatedStringRef if there was such a thing, but when
that was proposed the decision was to just uses "const char*" for that.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210062 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
The implementation might be better to have a method is64Bit() in the class
SymbolicFile instead of having the static routine isSymbolList64Bit() in
llvm-nm.cpp . But this is very much in the sprit of isObject() and
getNMTypeChar() in llvm-nm.cpp that has a series of if else statements
based on the specific class of the SymbolicFile. I can update this if
folks would like.
Also the tests were updated to be explicit about checking the address for
64-bits or 32-bits from object files.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208463 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r205479.
It turns out that nm does use addresses, it is just that every reasonable
relocatable ELF object has sections with address 0. I have no idea if those
exist in reality, but it at least it shows that llvm-nm should use the name
address.
The added test was includes an unusual .o file with non 0 section addresses. I
created it by hacking ELFObjectWriter.cpp.
Really sorry for the churn.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@205493 91177308-0d34-0410-b5e6-96231b3b80d8
What llvm-nm prints depends on the file format. On ELF for example, if the
file is relocatable, it prints offsets. If it is not, it prints addresses.
Since it doesn't really need to care what it is that it is printing, use the
generic term value.
Fix or implement getSymbolValue to keep llvm-nm working.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@205479 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
Microsoft PE/COFF Spec clearly states that the field is of signed interger
type. However, in reality, it's unsigned. If cl.exe needs to create a large
number of sections for COMDAT sections, it will just create more than 32768
sections. Handling large section number as negative number is not correct.
I think this is a spec bug.
Differential Revision: http://llvm-reviews.chandlerc.com/D3088
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203986 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
This interface allows IRObjectFile to be implemented without having dummy
methods for all section and segment related methods.
Both llvm-ar and llvm-nm are changed to use it. Unfortunately the mangler is
still not plugged in since it requires some refactoring to make a Module hold
a DataLayout.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201881 91177308-0d34-0410-b5e6-96231b3b80d8
It is not clear how much we should try to expose in getFlags. For example,
should there be a SF_Object and a SF_Text?
But for information that is already being exposed, we may as well use it in
llvm-nm.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200820 91177308-0d34-0410-b5e6-96231b3b80d8
COFF has only one symbol table.
MachO has a LC_DYSYMTAB, but that is not a symbol table, just extra info about
the one symbol table (LC_SYMTAB).
IR (coming soon) also has only one table.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200488 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
It had grown fairly inconsistent. I am about to change it quite a bit to also
use the object api when handling IR files.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200374 91177308-0d34-0410-b5e6-96231b3b80d8
identify_magic is not free, so we should avoid calling it twice. The argument
also makes it cheap for createBinary to just forward to createObjectFile.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199813 91177308-0d34-0410-b5e6-96231b3b80d8
I did write a version returning ErrorOr<OwningPtr<Binary> >, but it is too
cumbersome to use without std::move. I will keep the patch locally and submit
when we switch to c++11.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199326 91177308-0d34-0410-b5e6-96231b3b80d8
This puts all the global PassManager debugging flags, like
-print-after-all and -time-passes, behind a managed static. This
eliminates their static initializers and, more importantly, exit-time
destructors.
The only behavioral change I anticipate is that tools need to
initialize the PassManager before parsing the command line in order to
export these options, which makes sense. Tools that already initialize
the standard passes (opt/llc) don't need to do anything new.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@190974 91177308-0d34-0410-b5e6-96231b3b80d8
It was only used to implement ExecuteAndWait and ExecuteNoWait. Expose just
those two functions and make Execute and Wait implementations details.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183864 91177308-0d34-0410-b5e6-96231b3b80d8
Improve performance of iterating over children and accessing the member file
buffer by caching the file size and moving code out to the header.
This also makes getBuffer return a StringRef instead of a MemoryBuffer. Both
fixing a memory leak and removing a malloc.
This takes getBuffer from ~10% of the time in lld to unmeasurable.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174272 91177308-0d34-0410-b5e6-96231b3b80d8
into their new header subdirectory: include/llvm/IR. This matches the
directory structure of lib, and begins to correct a long standing point
of file layout clutter in LLVM.
There are still more header files to move here, but I wanted to handle
them in separate commits to make tracking what files make sense at each
layer easier.
The only really questionable files here are the target intrinsic
tablegen files. But that's a battle I'd rather not fight today.
I've updated both CMake and Makefile build systems (I think, and my
tests think, but I may have missed something).
I've also re-sorted the includes throughout the project. I'll be
committing updates to Clang, DragonEgg, and Polly momentarily.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171366 91177308-0d34-0410-b5e6-96231b3b80d8
Again, tools are trickier to pick the main module header for than
library source files. I've started to follow the pattern of using
LLVMContext.h when it is included as a stub for program source files.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169252 91177308-0d34-0410-b5e6-96231b3b80d8
