At least not in the interface exposed by ObjectFile. This matches what ELF and
COFF implement.
Adjust existing code that was expecting them to have values. No overall
functionality change intended.
Another option would be to change the interface and the ELF and COFF
implementations to say that the value of a common symbol is its size.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@241593 91177308-0d34-0410-b5e6-96231b3b80d8
This commit adds a 'run-pass' option to llc, which instructs the compiler to run
one specific code generation pass only.
Llc already has the 'start-after' and the 'stop-after' options, and this new
option complements the other two by making it easier to write tests that want
to invoke a single pass only.
Reviewers: Duncan P. N. Exon Smith
Differential Revision: http://reviews.llvm.org/D10776
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@241476 91177308-0d34-0410-b5e6-96231b3b80d8
When talking about the virtual address of sections the coff spec says:
... for simplicity, compilers should set this to zero. Otherwise, it is an
arbitrary value that is subtracted from offsets during relocation.
We don't currently subtract it, so check that it is zero.
If some producer does create such files, we can change getRelocationOffset
instead.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@241447 91177308-0d34-0410-b5e6-96231b3b80d8
Requested by Eugene Rozenfeld of the LLILC team, this feature allows JIT
clients to skip relocations for selected external symbols by returning ~0ULL
from their symbol resolver. If this value is returned for a given symbol,
RuntimeDyld will skip all relocations for that symbol. The client will be
responsible for applying the skipped relocations manually before the code
is executed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@241383 91177308-0d34-0410-b5e6-96231b3b80d8
SHT_NOBITS sections do not have content in an object file. Now the yaml2obj
tool does not accept `Content` field for such sections, and the obj2yaml
tool does not attempt to read the section content from a file.
Restore r241350 and r241352.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@241377 91177308-0d34-0410-b5e6-96231b3b80d8
r241350 broke lld tests.
r241352 depends on r241350.
Original messages:
"[ELFYAML] Fix handling SHT_NOBITS sections by obj2yaml/yaml2obj tools"
"[ELFYAML] Make the Size field for .bss section optional"
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@241354 91177308-0d34-0410-b5e6-96231b3b80d8
SHT_NOBITS sections do not have content in an object file. Now yaml2obj
tool does not accept `Content` field for such sections, and obj2yaml
tool does not attempt to read the section content from a file.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@241350 91177308-0d34-0410-b5e6-96231b3b80d8
This function can really fail since the string table offset can be out of
bounds.
Using ErrorOr makes sure the error is checked.
Hopefully a lot of the boilerplate code in tools/* can go away once we have
a diagnostic manager in Object.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@241297 91177308-0d34-0410-b5e6-96231b3b80d8
This patch changes linkage with dbghlp.dll for clang from static (at load time)
to on demand (at the first use of required functions). Clang uses dbghlp.dll
only in minor use-cases. First of all in case of crash and in case of plugin load.
The dbghlp.dll library can be absent on system. In this case clang will fail
to load. With lazy load of dbghlp.dll clang can work even if dbghlp.dll
is not available.
Differential Revision: http://reviews.llvm.org/D10737
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@241271 91177308-0d34-0410-b5e6-96231b3b80d8
This also improves the logic of what is an error:
* getSection(uint_32): only return an error if the index is out of bounds. The
index 0 corresponds to a perfectly valid entry.
* getSection(Elf_Sym): Returns null for symbols that normally don't have
sections and error for out of bound indexes.
In many places this just moves the report_fatal_error up the stack, but those
can then be fixed in smaller patches.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@241156 91177308-0d34-0410-b5e6-96231b3b80d8
Add all the new `Metadata` codes since LLVM 3.6, and at the same time
follow the precedent set in other blocks by removing the `METADATA_`
prefix from the string output.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@241016 91177308-0d34-0410-b5e6-96231b3b80d8
This change unifies how LTOModule and the backend obtain linker flags
for globals: via a new TargetLoweringObjectFile member function named
emitLinkerFlagsForGlobal. A new function LTOModule::getLinkerOpts() returns
the list of linker flags as a single concatenated string.
This change affects the C libLTO API: the function lto_module_get_*deplibs now
exposes an empty list, and lto_module_get_*linkeropts exposes a single element
which combines the contents of all observed flags. libLTO should never have
tried to parse the linker flags; it is the linker's job to do so. Because
linkers will need to be able to parse flags in regular object files, it
makes little sense for libLTO to have a redundant mechanism for doing so.
The new API is compatible with the old one. It is valid for a user to specify
multiple linker flags in a single pragma directive like this:
#pragma comment(linker, "/defaultlib:foo /defaultlib:bar")
The previous implementation would not have exposed
either flag via lto_module_get_*deplibs (as the test in
TargetLoweringObjectFileCOFF::getDepLibFromLinkerOpt was case sensitive)
and would have exposed "/defaultlib:foo /defaultlib:bar" as a single flag via
lto_module_get_*linkeropts. This may have been a bug in the implementation,
but it does give us a chance to fix the interface.
Differential Revision: http://reviews.llvm.org/D10548
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@241010 91177308-0d34-0410-b5e6-96231b3b80d8
This moves the error checking for string tables to getStringTable which returns
an ErrorOr<StringRef>.
This improves error checking, makes it uniform across all string tables and
makes it possible to check them once instead of once per name.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240950 91177308-0d34-0410-b5e6-96231b3b80d8
It was a fairly broken concept for an ELF only class.
An ELF file can have two symbol tables, but they have exactly the same
format. There is no concept of a dynamic or a static symbol. Storing this
on the iterator also makes us do more work per symbol than necessary. To fetch
a name we would:
* Find if we had a static or a dynamic symbol.
* Look at the corresponding symbol table and find the string table section.
* Look at the string table section to fetch its contents.
* Compute the name as a substring of the string table.
All but the last step can be done per symbol table instead of per symbol. This
is a step in that direction.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240939 91177308-0d34-0410-b5e6-96231b3b80d8
The parser provides a convenient interface for reading llvm stackmap v1 sections
in object files.
This patch also includes a new option for llvm-readobj, '-stackmap', which uses
the parser to pretty-print stackmap sections for debugging/testing purposes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240860 91177308-0d34-0410-b5e6-96231b3b80d8
This is still a really odd function. Most calls are in object format specific
contexts and should probably be replaced with a more direct query, but at least
now this is not too obnoxious to use.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240777 91177308-0d34-0410-b5e6-96231b3b80d8
Replace the `std::vector<>` for `DIE::Children` with an intrusively
linked list. This is a strict memory improvement: it requires no
auxiliary storage, and reduces `sizeof(DIE)` by one pointer. It also
factors out the DIE-related malloc traffic.
This drops llc memory usage from 735 MB down to 718 MB, or ~2.3%.
(I'm looking at `llc` memory usage on `verify-uselistorder.lto.opt.bc`;
see r236629 for details.)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240736 91177308-0d34-0410-b5e6-96231b3b80d8
Change `DIE::Values` to a singly linked list, where each node is
allocated on a `BumpPtrAllocator`. In order to support `push_back()`,
the list is circular, and points at the tail element instead of the
head. I abstracted the core list logic out to `IntrusiveBackList` so
that it can be reused for `DIE::Children`, which also cares about
`push_back()`.
This drops llc memory usage from 799 MB down to 735 MB, about 8%.
(I'm looking at `llc` memory usage on `verify-uselistorder.lto.opt.bc`;
see r236629 for details.)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240733 91177308-0d34-0410-b5e6-96231b3b80d8
Split out code to patch up the `DW_AT_stmt_list` for the cloned DIE, and
reorganize it so that it doesn't depend on `DIE::values_begin()` and
`DIE::values_end()` (which I'm trying to kill off).
David Blaikie and I talked about adding a range-algorithm version of
`std::find_if()`, but the assertion *still* required getting at the end
iterator. IMO, a separate helper function with an early return is
easier to reason about here.
A follow-up commit that removes `DIE::setValue()` and mutates the
`DIEValue` directly is coming shortly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240701 91177308-0d34-0410-b5e6-96231b3b80d8
* Have it return a iterator_range.
* Remove the global function.
* Rename to getDynamicSymbolIterators.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240644 91177308-0d34-0410-b5e6-96231b3b80d8
On ELF that was already the case since getting the size of a symbol
never fails.
On MachO and COFF we could fail trying to get the section of a symbol. But
we don't really need the section, just the section number to know if two
symbols are in the same section or not.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240580 91177308-0d34-0410-b5e6-96231b3b80d8
It is perfectly possible for SHNDX to contain indexes that have the same value
as reserved st_shndx values.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240544 91177308-0d34-0410-b5e6-96231b3b80d8
COFF and MachO only define symbol sizes for common symbols. Reflect that
in the class hierarchy by having a method for common symbols only in the base
and a general one in ELF.
This avoids the need of using a magic value for the size, which had a few
problems
* Most callers didn't check for it.
* The ones that did could not tell the magic value from a file actually having
that value.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240529 91177308-0d34-0410-b5e6-96231b3b80d8
This patch adds the -mcpu= option to llvm-rtdyld. With this option, one
can test relocations for different types of CPUs (e.g. Mips64r6).
Patch by Vladimir Radosavljevic.
Differential Revision: http://reviews.llvm.org/D10503
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240477 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
lto_codegen_set_should_embed_uselists is introduced in r235943 but not
added to lto.exports. Add to export list to expose the API.
Reviewers: dexonsmith
Subscribers: rafael, llvm-commits
Differential Revision: http://reviews.llvm.org/D10658
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240442 91177308-0d34-0410-b5e6-96231b3b80d8
Only common symbol on MachO and COFF have a size.
For COFF we already had a custom format.
For MachO, there is no native objdump and we were printing it as ELF. Now
we only print the sizes for symbols that actually have them.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240422 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
That way llvm-objdump can rely on it without adding an extra dependency
on CodeGen.
This change duplicates the FaultKind enum and the code that serializes
it to a string. I could not figure out a way to get around this without
adding a new dependency to Object
Reviewers: rafael, ab
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D10619
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240364 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: I don't think anyone is relying on this behavior for bootstrapping (because I don't think it works), but if you do need it, speak now or forever hold your peace.
Reviewers: chapuni, samsonov
Reviewed By: samsonov
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D10613
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240344 91177308-0d34-0410-b5e6-96231b3b80d8
The reason we need to search by name rather than by Triple::ArchType
is to handle subarchitecture correclty. There is no different ArchType
for the x86_64h architecture (it identifies itself as x86_64), or for
the various ARM subarches. The only way to get to the subarch slice
in an universal binary is to search by name.
This issue led to hard to debug and transient symbolication failures
in Asan tests (it mostly works, because the files are very similar).
This also affects the Profiling infrastucture as it is the other user
of that API.
Reviewers: samsonov, bogner
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D10604
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240339 91177308-0d34-0410-b5e6-96231b3b80d8
There are 3 types of relocations on MachO
* Scattered
* Section based
* Symbol based
On ELF and COFF relocations are symbol based.
We were in the strange situation that we abstracted over two of them. This makes
section based relocations MachO only.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240149 91177308-0d34-0410-b5e6-96231b3b80d8
In a relocation target can take 3 basic forms
* A r_value in scattered relocations.
* A symbol in external relocations.
* A section is non-external relocations.
Have the dump reflect that. With this change we go from
CHECK-NEXT: Extern: 0
CHECK-NEXT: Type: X86_64_RELOC_SUBTRACTOR (5)
CHECK-NEXT: Symbol: 0x2
CHECK-NEXT: Scattered: 0
To just
// CHECK-NEXT: Type: X86_64_RELOC_SUBTRACTOR (5)
// CHECK-NEXT: Section: __data (2)
Since the relocation is with a section, we print the seciton name and don't
need to say that it is not scattered or external.
Someone motivated can add further special cases for things like
ARM64_RELOC_ADDEND and ARM_RELOC_PAIR.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240073 91177308-0d34-0410-b5e6-96231b3b80d8
The personality routine currently lives in the LandingPadInst.
This isn't desirable because:
- All LandingPadInsts in the same function must have the same
personality routine. This means that each LandingPadInst beyond the
first has an operand which produces no additional information.
- There is ongoing work to introduce EH IR constructs other than
LandingPadInst. Moving the personality routine off of any one
particular Instruction and onto the parent function seems a lot better
than have N different places a personality function can sneak onto an
exceptional function.
Differential Revision: http://reviews.llvm.org/D10429
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@239940 91177308-0d34-0410-b5e6-96231b3b80d8
Directional labels can show up in symbol tables (and we have a llvm-mc test for
that). Given that, we need to make sure they are named.
With that out of the way, use setUseNamesOnTempLabels in llvm-mc so that it
too benefits from the memory saving.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@239914 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This continues the patch series to eliminate StringRef forms of GNU triples
from the internals of LLVM that began in r239036.
Reviewers: rengolin
Reviewed By: rengolin
Subscribers: llvm-commits, rengolin
Differential Revision: http://reviews.llvm.org/D10381
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@239815 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This affects other tools so the previous C++ API has been retained as a
deprecated function for the moment. Clang has been updated with a trivial
patch (not covered by the pre-commit review) to avoid breaking -Werror builds.
Other in-tree tools will be fixed with similar patches.
This continues the patch series to eliminate StringRef forms of GNU triples
from the internals of LLVM that began in r239036.
The first time this was committed it accidentally fixed an inconsistency in
triples in llvm-mc and this caused a failure. This inconsistency was fixed in
r239808.
Reviewers: rengolin
Reviewed By: rengolin
Subscribers: llvm-commits, rengolin
Differential Revision: http://reviews.llvm.org/D10366
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@239812 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
GetTarget() may modify TripleName without also updating TheTriple.
This can lead to situations where the MCObjectStreamer has a different triple
to the rest of LLVM.
This inconsistency caused sparc-little-endian.s to pass on Windows because most
of LLVM had sparcel-pc-win32 while MCObjectStreamer had "". I believe the same
kind of thing was also true of Darwin.
Reviewers: rengolin
Reviewed By: rengolin
Subscribers: llvm-commits, rengolin, rafael
Differential Revision: http://reviews.llvm.org/D10450
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@239808 91177308-0d34-0410-b5e6-96231b3b80d8
Fix a build failure with `LLVM_ENABLE_MODULES` due to
`ProfileData::instr` conflicting with a function `instr()` in
`<curses.h>`.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@239793 91177308-0d34-0410-b5e6-96231b3b80d8
This commit connects the machine function analysis pass (which creates machine
functions) to the MIR parser, which will initialize the machine functions
with the state from the MIR file and reconstruct the machine IR.
This commit introduces a new interface called 'MachineFunctionInitializer',
which can be used to provide custom initialization for the machine functions.
This commit also introduces a new diagnostic class called
'DiagnosticInfoMIRParser' which is used for MIR parsing errors.
This commit modifies the default diagnostic handling in LLVMContext - now the
the diagnostics are printed directly into llvm::errs() so that the MIR parsing
errors can be printed with colours.
Reviewers: Justin Bogner
Differential Revision: http://reviews.llvm.org/D9928
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@239753 91177308-0d34-0410-b5e6-96231b3b80d8
The plugin now save the bitcode before and after optimizations and the
.o that is passed to the linker.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@239726 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This affects other tools so the previous C++ API has been retained as a
deprecated function for the moment. Clang has been updated with a trivial
patch (not covered by the pre-commit review) to avoid breaking -Werror builds.
Other in-tree tools will be fixed with similar trivial patches.
This continues the patch series to eliminate StringRef forms of GNU triples
from the internals of LLVM that began in r239036.
Reviewers: rengolin
Reviewed By: rengolin
Subscribers: llvm-commits, rengolin
Differential Revision: http://reviews.llvm.org/D10366
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@239721 91177308-0d34-0410-b5e6-96231b3b80d8
into partitions. Also, add an option to clone stub definitions (not just decls)
into partitions: these definitions could be inlined in some places to avoid the
overhead of calling via the stub.
Found by inspection - no test case yet, although I plan to add a unit test for
this once the CompileOnDemand layer refactoring settles down.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@239640 91177308-0d34-0410-b5e6-96231b3b80d8
As suggested by jroelofs in a prior review (D9752),
it makes sense to generally prefer multi-line format.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@239632 91177308-0d34-0410-b5e6-96231b3b80d8
