The code this patch removes was there to make sure the text sections went
before the dwarf sections. That is necessary because MachO uses offsets
relative to the start of the file, so adding a section can change relaxations.

The dwarf sections were being printed at the start just to produce symbols
pointing at the start of those sections.

The underlying issue was fixed in r231898. The dwarf sections are now printed
when they are about to be used, which is after we printed the text sections.

To make sure we don't regress, the patch makes the MachO streamer assert
if CodeGen puts anything unexpected after the DWARF sections.

llvm-svn: 232842

Remove `DebugInfoVerifierLegacyPass` and the `-verify-di` pass.
Instead, call into the `DebugInfoVerifier` from inside
`VerifierLegacyPass::finalizeModule()`.  This better matches the logic
in `verifyModule()` (used by the new PassManager), avoids requiring two
separate passes to verify the IR, and makes the API for "add a pass to
verify the IR" simple.

Note: the `-verify-debug-info` flag still works (for now, at least;
eventually it might make sense to just remove it).

llvm-svn: 232772

llvm-svn: 232771

This change also introduces a link-time optimization level of 1. This
optimization level runs only the globaldce pass as well as cleanup passes for
passes that run at -O0, specifically simplifycfg which cleans up lowerbitsets.

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20150316/266951.html

llvm-svn: 232769

`StripDebug` was only used by tools/opt/opt.cpp in
`AddStandardLinkPasses()`, but opt.cpp adds the same pass based on its
command-line flag before it calls `AddStandardLinkPasses()`.  Stripping
debug info twice isn't very useful.

llvm-svn: 232765

This is an ugly hack to fix the configure --enable-shared build. It
turns out that *every cl::opt in LLVM* shows up in *every tool* in
that configuration, which is hopelessly broken. This skirts around the
issue by not colliding with another option's name, for now.

I've also simplified the option implementation - the other "color"
option used cl::boolOrDefault and was much nicer than what I'd written
before.

llvm-svn: 232704

This bot doesn't like me. I don't know why:

    http://lab.llvm.org:8011/builders/clang-hexagon-elf/builds/24425

Move the color option enum's definition out of the function that
creates the cl::opt.

llvm-svn: 232700

The clang-hexagon elf bot was complaining that "Option 'color'
registered more than once!":

    http://lab.llvm.org:8011/builders/clang-hexagon-elf/builds/24425

I don't understand why this error is happening, and I don't see it on
any other bots or on my own machine, so I'm kind of grasping at
straws. Try using an unscoped enum and specifying a cl::init to see if
they help.

llvm-svn: 232698

This replaces the -no-color flag with a -color={auto|always|never}
option, with auto as the default, which is much saner.

llvm-svn: 232693

llvm-svn: 232663

The MSVC linker won't produce a .lib file for an executable that doesn't
export anything, and LLVM doesn't maintain dllexport annotations or .def
files listing all C++ symbols. It also doesn't support exporting all
symbols, like binutils ld.

CMake 3.2 changed the Ninja generator to list both the .exe and .lib
files as outputs of executable build targets. Ninja would always re-link
executables with ENABLE_EXPORTS because the .lib output file was not
present, and therefore the target was out of date.

llvm-svn: 232662

[Objdump] DumpBytes of uint8_t from ArrayRef<uint8_t> instead of char from StringRef.  Removing reinterpret_casts.

llvm-svn: 232659

llvm-svn: 232654

-disassemble to not symbolic operands when disassembling.

llvm-svn: 232558

-disassemble or -section to not print the leading addresses on each line.

llvm-svn: 232547

Before this patch code wanting to create temporary labels for a given entity
(function, cu, exception range, etc) had to keep its own counter to have stable
symbol names.

createTempSymbol would still add a suffix to make sure a new symbol was always
returned, but it kept a single counter. Because of that, if we were to use
just createTempSymbol("cu_begin"), the label could change from cu_begin42 to
cu_begin43 because some other code started using temporary labels.

Simplify this by just keeping one counter per prefix and removing the various
specialized counters.

llvm-svn: 232535

-disassemble to disassemble just one symbol’s instructions.

llvm-svn: 232503

Despite using the same name these are unrelated.

llvm-svn: 232485

llvm-svn: 232484

llvm-svn: 232429

to print the Mach-O dynamic shared libraries used by a linked image or the
library id of a shared library.

llvm-svn: 232406

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.

llvm-svn: 232342

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.

llvm-svn: 232335

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.

llvm-svn: 232333

llvm-svn: 232305

llvm-vtabledump has grown enough functionality not related to vtables
that it deserves a name which is more descriptive.

llvm-svn: 232301

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.

llvm-svn: 232300

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.

llvm-svn: 232267

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.

llvm-svn: 232246

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.

llvm-svn: 232245

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...

llvm-svn: 232234

llvm-svn: 232233

Nothing fancy, just a straightforward offset to apply to the original
debug_ranges entries to get them in line with the linked addresses.

llvm-svn: 232232

llvm-svn: 232231

This speeds up llvm-ar building lib64/libclangSema.a with debug IR files
from 8.658015807 seconds to just 0.351036519 seconds :-)

llvm-svn: 232221

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.

llvm-svn: 232193

They need to be handled specifically as they could vary pretty
widely depending on how the linker moves functions around.

llvm-svn: 232192

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.

llvm-svn: 232191

using numeric values and not their symbolic constant names.

The routines that print Mach-O stuff already had a verbose parameter and this
change is just changing the passing true to passing !NonVerbose.  With just a
couple of fixes and a bunch of test case updates.

llvm-svn: 232182

This reverts commit r231967 which reinstates r231957.

Now that IntervalMap uses explicitely aligned storage, it should be safe.

llvm-svn: 232080