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
