Prevent all the unrelated LLVM options to appear in the -help output
by introducing a tool specific option category. As a drive-by improve
the wording of the help message.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@243583 91177308-0d34-0410-b5e6-96231b3b80d8
The dsymutil-classic -v option dumps the tool version rather than
putting it in verbose mode. Rename -v to -verbose and update the
tests that use it (in the process removing it from a few tests that
didn't require it anymore since the -dump-debug-map option was
introduced).
A followup commit will reintroduce the -v option that dumps the
version.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@243582 91177308-0d34-0410-b5e6-96231b3b80d8
This patch allows llvm-dsymutil to read universal (aka fat) macho object
files and archives. The patch touches nearly everything in the BinaryHolder,
but it is fairly mechinical: the methods that returned MemoryBufferRefs or
ObjectFiles now return a vector of those, and the high-level access function
takes a triple argument to select the architecture.
There is no support yet for handling fat executables and thus no support for
writing fat object files.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@243096 91177308-0d34-0410-b5e6-96231b3b80d8
MachOObjectFile offers a method for detecting the correct triple, use
it instead of the previous approximation. This doesn't matter right
now, but it will become important for mach-o universal (fat) binaries.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@243095 91177308-0d34-0410-b5e6-96231b3b80d8
Call a helper that resets all the internal state of the BinaryHolder
when we change the underlying memory buffer. Makes a followup patch
a tiny bit smaller.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@243094 91177308-0d34-0410-b5e6-96231b3b80d8
The debug map contains the timestamp of the object files in references.
We do not check these in the general case, but it's really useful if
you have archives where different versions of an object file have been
appended. This allows llvm-dsymutil to find the right one.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@242965 91177308-0d34-0410-b5e6-96231b3b80d8
This optimization allows the DWARF linker to reuse definition of
types it has emitted in previous CUs rather than reemitting them
in each CU that references them. The size and link time gains are
huge. For example when linking the DWARF for a debug build of
clang, this generates a ~150M dwarf file instead of a ~700M one
(the numbers date back a bit and must not be totally accurate
these days).
As with all the other parts of the llvm-dsymutil codebase, the
goal is to keep bit-for-bit compatibility with dsymutil-classic.
The code is littered with a lot of FIXMEs that should be
addressed once we can get rid of the compatibilty goal.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@242847 91177308-0d34-0410-b5e6-96231b3b80d8
r224810 fixed the handling of macro debug locations in AsmParser. This patch
fixes the logic to actually do what was intended: it uses the first macro of
the macro stack instead of the last one. The updated testcase shows that the
current scheme doesn't work when macro instanciations are nested and multiple
files are used.
Reviewers: compnerd
Differential Revision: http://reviews.llvm.org/D10463
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240705 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
Linking the debug frame section is actually very easy as we just have to
patch the start address in the FDE header and then copy the rest of the
FDE without even looking at it. The only small complexity comes from the
handling of the CIEs that we should unique across object file. This is
also really easy by using a StringMap keyed on the raw contents of the
CIE.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@239198 91177308-0d34-0410-b5e6-96231b3b80d8
Anyway having the type and the name of the member being the same
thing wasn't the wisest of the choices.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@239190 91177308-0d34-0410-b5e6-96231b3b80d8
The main use of the YAML debug map format is for testing inside LLVM. If we have IR
files in the tests used to generate object files, then we obviously don't know the
addresses of the symbols inside the object files beforehand.
This change lets the YAML import lookup the addresses in the object files and rewrite
them. This will allow to have test that really don't need any binary input.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@239189 91177308-0d34-0410-b5e6-96231b3b80d8
It will get a bit bigger in an upcoming commit. No need to have all
of that in the header.
Also move parseYAMLDebugMap() to the same place as the serialization
code. This way it will be able to share a private Context object with
it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@239185 91177308-0d34-0410-b5e6-96231b3b80d8
With a couple more constructors that GCC thinks are necessary.
Original commit message:
[dsymutil] Accept a YAML debug map as input instead of a binary.
To do this, the user needs to pass the new -y flag.
As it wasn't tested before, the debug map YAML deserialization was
completely buggy (mainly because the DebugMapObject has a dual
mapping that allows to search by name and by address, but only the
StringMap got populated). It's fixed and tested in this commit by
augmenting some test with a 2 stage dwarf link: a frist llvm-dsymutil
reads the debug map and pipes it in a second instance that does the
actual link without touching the initial binary.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@238959 91177308-0d34-0410-b5e6-96231b3b80d8
To do this, the user needs to pass the new -y flag.
As it wasn't tested before, the debug map YAML deserialization was
completely buggy (mainly because the DebugMapObject has a dual
mapping that allows to search by name and by address, but only the
StringMap got populated). It's fixed and tested in this commit by
augmenting some test with a 2 stage dwarf link: a frist llvm-dsymutil
reads the debug map and pipes it in a second instance that does the
actual link without touching the initial binary.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@238941 91177308-0d34-0410-b5e6-96231b3b80d8
As the serialized debug map is becoming a first class citizen, a way
to cleanly dump it is required. We used -parse-only combined with
-v for that purpose before, but it dumps a lot of unrelated debug
stuff. Dumping the debug map was the only use of the -parse-only flag
anyway, so replace it with a more useful option.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@238940 91177308-0d34-0410-b5e6-96231b3b80d8
Doing so will allow us to also accept a YAML debug map in input as using
YAMLIO gives us the parsing for free. Being able to have textual debug
maps will in turn allow much more control over the tests, because 1/
no need to check-in a binary containing the debug map and 2/ it will allow
to use the same objects/IR files with made-up debug-maps to test
different scenari.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@238781 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
We would wrap flow mappings and sequences when they go over a hardcoded 70
characters limit. Make the wrapping column configurable (and default to 70
co the change should be NFC for current users). Passing 0 allows to completely
suppress the wrapping which makes it easier to handle in tools like FileCheck.
Reviewers: bogner
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D10109
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@238584 91177308-0d34-0410-b5e6-96231b3b80d8
It seems one windows bot fails since I added ilne table linking to
llvm-dsymutil (see r232333 commit thread).
Disable the affected tests until I can figure out what's happening.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@233130 91177308-0d34-0410-b5e6-96231b3b80d8
The information gathering part of the patch stores a bit more information
than what is strictly necessary for these 2 sections. The rest will
become useful when we start emitting __apple_* type accelerator tables.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232342 91177308-0d34-0410-b5e6-96231b3b80d8
Also, after looking at the raw_svector_stream internals, increase the
size of the SmallString used with it to prevent heap allocation.
Issue found by the Asan bot.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232335 91177308-0d34-0410-b5e6-96231b3b80d8
This code comes with a lot of cruft that is meant to mimic darwin's
dsymutil behavior. A much simpler approach (described in the numerous
FIXMEs that I put in there) gives the right output for the vast
majority of cases. The extra corner cases that are handled differently
need to be investigated: they seem to correctly handle debug info that
is in the input, but that info looks suspicious in the first place.
Anyway, the current code needs to handle this, but I plan to revisit it
as soon as the big round of validation against the classic dsymutil is
over.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232333 91177308-0d34-0410-b5e6-96231b3b80d8
No need to emit a DW_LNS_advance_pc with a 0 increment. Found out while
comparing dsymutil's and LLVM's line table encoding. Not a correctenss
fix, just a small encoding size optimization.
I'm not sure how to generate a sequence that triggers this, and moreover
llvm-dwardump doesn't dump the line table program, thus the effort
involved in creating a testcase for this trivial patch seemed out of
proportion.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232332 91177308-0d34-0410-b5e6-96231b3b80d8
The debug map embedded by ld64 in binaries conatins function sizes.
These sizes are less precise than the ones given by the debug information
(byte granularity vs linker atom granularity), but they might cover code
that is referenced in the line table but not in the DIE tree (that might
very well be a compiler bug that I need to investigate later).
Anyway, extracting that information is necessary to be able to mimic
dsymutil's behavior exactly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232300 91177308-0d34-0410-b5e6-96231b3b80d8
There is no need to look into the location expressions to transfer them,
the only modification to apply is to patch their base address to reflect
the linked function address.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232267 91177308-0d34-0410-b5e6-96231b3b80d8
This actually shares most of its implementation with the generation
of the debug_ranges (the absence of 'a' is not a typo) contribution
for the unit's DW_AT_ranges attribute.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232246 91177308-0d34-0410-b5e6-96231b3b80d8
The ID can eg. de used in MCSymbol names to differentiate the ones
that need to be created for every unit.
The ID is a constructor parameter and not a static class member so
there is no issue with counter updates if we decide to thread that
code.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232245 91177308-0d34-0410-b5e6-96231b3b80d8
Next time, when I fix a typo, I'll take the time to reread the whole
comment instead of waiting for the commit email to realize that there
is another one two words later...
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232234 91177308-0d34-0410-b5e6-96231b3b80d8
Nothing fancy, just a straightforward offset to apply to the original
debug_ranges entries to get them in line with the linked addresses.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232232 91177308-0d34-0410-b5e6-96231b3b80d8
We recorded the forward references in the CU that holds the referenced
DIE, but this is wrong as those will get resoled *after* the CU that
holds the reference. Record the references in their originating CU along
with a pointer to the remote CU to be able to compute the fixed up
offset at the right time.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232193 91177308-0d34-0410-b5e6-96231b3b80d8
They need to be handled specifically as they could vary pretty
widely depending on how the linker moves functions around.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232192 91177308-0d34-0410-b5e6-96231b3b80d8
The typo got unnoticed because we were testing only on Dwarf 2. Add a
Dwarf4 test that exercises the code path, and also tests some newer
FORMs that the other test doesn't cover.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232191 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r231967 which reinstates r231957.
Now that IntervalMap uses explicitely aligned storage, it should be safe.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232080 91177308-0d34-0410-b5e6-96231b3b80d8
Currently IntervalMap would assert when used with keys bigger than host
pointers. This patch uses the AlignedCharArrayUnion functionality to
overcome that limitation.
Differential Revision: http://reviews.llvm.org/D8268
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232079 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r231957.
IntervalMap currently doesn't support keys more aligned than host pointers
and I've been using it with uint64_t keys. This asserts on some 32bits
systems.
Revert while I work on an IntervalMap generalization.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@231967 91177308-0d34-0410-b5e6-96231b3b80d8
Gather the function ranges [low_pc, high_pc) during DIE selection and
store them along with the offset to apply to them to get the linked
addresses.
This is just the data collection part, it comes with no tests. That
information will be used in multiple followup commits to perform the
relocation of line tables and range sections among other things, and
these commits will add tests.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@231957 91177308-0d34-0410-b5e6-96231b3b80d8
DW_AT_low_pc on functions is taken care of by the relocation processing, but
DW_AT_high_pc and DW_AT_low_pc on other lexical scopes need special handling.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@231955 91177308-0d34-0410-b5e6-96231b3b80d8
Last commit fixed the handling of hash collisions, but it introdcuced
unneeded bucket terminators in some places. The generated table was
correct, it can just be a tiny bit smaller. As the previous table was
correct, the test doesn't need updating. If we really wanted to test
this, I could add the section size to the dwarf dump and test for a
precise value there. IMO the correctness test is sufficient.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@231748 91177308-0d34-0410-b5e6-96231b3b80d8
It turns out accelerator tables where totally broken if they contained
entries with colliding hashes. The failure mode is pretty bad, as it not
only impacted the colliding entries, but would basically make all the
entries after the first hash collision pointing in the wrong place.
The testcase uses the symbol names that where found to collide during a
clang build.
From a performance point of view, the patch adds a sort and a linear
walk over each bucket contents. While it has a measurable impact on the
accelerator table emission, it's not showing up significantly in clang
profiles (and I'd argue that correctness is priceless :-)).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@231732 91177308-0d34-0410-b5e6-96231b3b80d8
I have a test for that issue, but I didn't include it in the commit as it's
a 200KB file for a pretty minor issue. (The reason the file is so big is
that it needs > 1024 variables/functions to trigger and that with debug
information.
The issue/fix on the other side is totally trivial. If poeple want the test
commited, I can do that. It just didn't seem worth it to me.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@231701 91177308-0d34-0410-b5e6-96231b3b80d8
Doing this gets function's low_pc and global variable's locations right
in the output debug info. It also could get right other attributes
that need to be relocated (in linker terms), but I don't know of any
other than the address attributes.
This doesn't fixup low_pc attributes in compile_unit, lexical_block
or inlined subroutine, nor does it get right high_pc attributes
for function. This will come in a subsequent commit.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@231544 91177308-0d34-0410-b5e6-96231b3b80d8
Reference attributes are mainly handled by just creating DIEEntry
attributes for them. There is a special case for DW_FORM_ref_addr
attributes though, because the DIEEntry code needs a DwarfDebug
code to emit them (and we don't have one as we do no CodeGen).
In that case, just use DIEInteger attributes with the right form.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@231531 91177308-0d34-0410-b5e6-96231b3b80d8
The start offset of a linked unit is known before starting to clone
its DIEs. Handling DW_FORM_ref_addr attributes requires that this
offset is set while cloning the unit. Split CompileUnit::computeOffsets()
into setStartOffset() and computeNextUnitOffset() and call them
repsectively before cloning the DIEs and right after.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@231530 91177308-0d34-0410-b5e6-96231b3b80d8
This commit adds code to emit DIE trees that have been pruned from the
parts that haven't been marked as kept in the previous pass.
It works by 'cloning' the input DIE tree (as read by libDebugInfoDwarf)
into a tree of DIE objects. Cloning the DIEs means essentially cloning
their attributes. The code in this commit does only handle scalar and
block attributes (scalar because they are trivial, blocks because they
can't be easily replaced by a scalr placeholder), all the other ones
are replaced by placeholder zero values and will be handled in
further commits.
The added tests mostly check that the DIE tree has the correct layout and
also verify that a few chosen scalar and block attributes correctly make
their way into the output.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@231300 91177308-0d34-0410-b5e6-96231b3b80d8
The implementation accepts explicitely signed forms (DW_FORM_sdata),
but also unsigned forms as long as they fit in an int64_t.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@231299 91177308-0d34-0410-b5e6-96231b3b80d8
To be used/tested by llvm-dsymutil. (llvm-dsymutil does a 'static' link,
no need for relocations for most things, so it'll just emit raw integers
for most attributes)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@231298 91177308-0d34-0410-b5e6-96231b3b80d8
(They are called emitDwarfDIE and emitDwarfAbbrevs in their new home)
llvm-dsymutil wants to reuse that code, but it doesn't have a DwarfUnit or
a DwarfDebug object to call those. It has access to an AsmPrinter though.
Having emitDIE in the AsmPrinter also removes the DwarfFile dependency
on DwarfDebug, and thus the patch drops that field.
Differential Revision: http://reviews.llvm.org/D8024
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@231210 91177308-0d34-0410-b5e6-96231b3b80d8
This class is responsible for getting the linked data to the
disk in the appropriate form. Today it it an empty shell that
just instantiates an MC layer.
As we do not put anything in the resulting file yet, we just
check it has the right architecture (and check that -o does
the right thing).
To be able to create all the components, this commit adds a
few dependencies to llvm-dsymutil, namely all-targets, MC and
AsmPrinter.
Also add a -no-output option, so that tests that do not need
the binary result can continue to run even if they do not have
the required target linked in.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230824 91177308-0d34-0410-b5e6-96231b3b80d8
...and reimplement DwarfLinker::reportWarning in terms of it. Other
compenents than the DwarfLinker will need to report warnings, and I'm
about to add a similar "error()" helper at the same global level so
make that consistent.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230820 91177308-0d34-0410-b5e6-96231b3b80d8
On 32bits x86 Darwin, the register mappings for the eh_frane and
debug_frame sections are different. Thus the same CFI instructions
should result in different registers in the object file. The
problem isn't target specific though, but it requires that the
mappings for EH register numbers be different from the standard
Dwarf one.
The patch looks a bit clumsy. LLVM uses the EH mapping as
canonical for everything frame related. Thus we need to do a
double conversion EH -> LLVM -> Non-EH, when emitting the
debug_frame section.
Fixes PR22363.
Differential Revision: http://reviews.llvm.org/D7593
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230670 91177308-0d34-0410-b5e6-96231b3b80d8
Move the FrameEntry::dumpInstructions down in the file at some
place where it can see the declarations of FDE and CIE.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230549 91177308-0d34-0410-b5e6-96231b3b80d8
This is the first commit in a small series aiming at making
debug_frame dump more useful (right now it prints a list of
opeartions without their operands).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230547 91177308-0d34-0410-b5e6-96231b3b80d8
With this commit, llvm-dsymutil learns how to choose which DIEs
it will link in the final output and which ones it won't. This
is based on the 'valid relocation' information that has been
built in the previous commits.
The test only tests that we choose the right 'root DIEs'. The
selection algorithm (and especially the part that walk the
dependencies of a root DIE) lacks a bit test coverage. This
will be much easier to cover when we output actual Dwarf and
thus can use llvm-dwarfdump to verify the structure of the
emitted DIE trees. I'll add more tests then.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@229183 91177308-0d34-0410-b5e6-96231b3b80d8
To be used in dsymutil (or any other client that wants to take
advantage of the fact that DIEs are stored in a vector).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@229179 91177308-0d34-0410-b5e6-96231b3b80d8
These 'valid relocations' in the debug_info section will be how
dsymutil identifies the DIEs it needs to keep in the linked debug
information.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@229178 91177308-0d34-0410-b5e6-96231b3b80d8
It turns out the debug map will be interogated both by name and
by object file address. Add the latter capability.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@229177 91177308-0d34-0410-b5e6-96231b3b80d8
The ARM assembler allows register alias redefinitions as long as it
targets the same register. r222319 broke that. In the AArch64 case
it would just produce a new warning, but in the ARM case it would
error out on previously accepted assembler.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228109 91177308-0d34-0410-b5e6-96231b3b80d8
The libDebugInfo DIE parsing doesn't store these relationships, we have to
recompute them. This commit introduces the CompileUnit bookkeeping class to
store this data. It will be expanded with more fields in the future.
No tests as this produces no visible output.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227382 91177308-0d34-0410-b5e6-96231b3b80d8
Parsed DIEs are stored in a vector and that makes it easy to get their
indices. Having easy access to a DIE's index makes it possible to use
arrays or vectors to efficiently store/access DIE related information.
There's no test for that new functionality (I don't see how to test
it standalone), but it'll be used in a subsequent dsymutil commit.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227381 91177308-0d34-0410-b5e6-96231b3b80d8
It's an empty shell for now. It's main method just opens the debug
map objects and parses their Dwarf info. Test that we at least do
that correctly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227337 91177308-0d34-0410-b5e6-96231b3b80d8
It will be needed to instantiate the Target object that we will
use to create all the MC objects for the dwarf emission.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226525 91177308-0d34-0410-b5e6-96231b3b80d8
dsymutil would like to use all the AsmPrinter/MCStreamer infrastructure
to stream out the DWARF. In order to do so, it will reuse the DIE object
and so this header needs to be public.
The interface exposed here has some corners that cannot be used without a
DwarfDebug object, but clients that want to stream Dwarf can just avoid
these.
Differential Revision: http://reviews.llvm.org/D6695
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@225208 91177308-0d34-0410-b5e6-96231b3b80d8
This object is meant to own the ObjectFiles and their underlying
MemoryBuffer. It is basically the equivalent of an OwningBinary
except that it efficiently handles Archives. It is optimized for
efficiently providing mappings of members of the same archive when
they are opened successively (which is standard in Darwin debug
maps, objects from the same archive will be contiguous).
Of course, the BinaryHolder will also be used by the DWARF linker
once it is commited, but for now only the debug map parser uses it.
With this change, you can run llvm-dsymutil on your Darwin debug build
of clang and get a complete debug map for it.
Differential Revision: http://reviews.llvm.org/D6690
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@225207 91177308-0d34-0410-b5e6-96231b3b80d8
Frederic Riss