llvm-dwp.cpp has the following include chain:
llvm/CodeGen/AsmPrinter.h
llvm/CodeGen/MachineFunctionPass.h
llvm/CodeGen/MachineFunction.h
llvm/CodeGen/MachineBasicBlock.h
llvm/CodeGen/MachineInstr.h
llvm/Analysis/AliasAnalysis.h
llvm/IR/CallSite.h
llvm/IR/Attributes.h
llvm/IR/Attributes.gen
This means llvm-dwp needs to depend on intrinsics_gen.
llvm-svn: 287429
In preparation for a follow on patch that improves DWARF parsing speed, clean up DWARFFormValue so that we have can get the fixed byte size of a form value given a DWARFUnit or given the version, address byte size and dwarf32/64.
This patch cleans up code so that everyone is using one of the new DWARFFormValue functions:
static Optional<uint8_t> DWARFFormValue::getFixedByteSize(dwarf::Form Form, const DWARFUnit *U = nullptr);
static Optional<uint8_t> DWARFFormValue::getFixedByteSize(dwarf::Form Form, uint16_t Version, uint8_t AddrSize, bool Dwarf32);
This patch changes DWARFFormValue::skipValue() to rely on the output of DWARFFormValue::getFixedByteSize(...) instead of duplicating the code in each function. This will reduce the number of changes we need to make to DWARF to fewer places in DWARFFormValue when we add support for new form.
This patch also starts to support DWARF64 so that we can get correct byte sizes for forms that vary according the DWARF 32/64.
To reduce the code duplication a new FormSizeHelper pure virtual class was created that can be created as a FormSizeHelperDWARFUnit when you have a DWARFUnit, or FormSizeHelperManual where you manually specify the DWARF version, address byte size and DWARF32/DWARF64. There is now a single implementation of a function that gets the fixed byte size (instead of two where one took a DWARFUnit and one took the DWARF version, address byte size and DWARFFormat enum) and one function to skip the form values.
https://reviews.llvm.org/D26526
llvm-svn: 286597
This is forcing to use Error::success(), which is in a wide majority
of cases a lot more readable.
Differential Revision: https://reviews.llvm.org/D26481
llvm-svn: 286561
Some targets, notably AArch64 for ILP32, have different relocation encodings
based upon the ABI. This is an enabling change, so a future patch can use the
ABIName from MCTargetOptions to chose which relocations to use. Tested using
check-llvm.
The corresponding change to clang is in: http://reviews.llvm.org/D16538
Patch by: Joel Jones
Differential Revision: https://reviews.llvm.org/D16213
llvm-svn: 276654
Richard Smith identified this in post commit review of r270466. The
string sections in particular (in the future, possibly all sections - so
I'm not going to bother pulling out just the string sections for the
extra lifetime handling right now) need to remain valid during
processing of all inputs so that elements of the DWPStringPool can be
looked up repeatedly without having to make in-memory copies of string
contents in the noncompressed case (more common in dwp+dwp merge steps
where the memory is a bigger problem because the files are larger).
Using the SmallVector (or any vector) a reallocation on push_back could
cause any of the nested SmallStrings in small mode to move in memory and
invalid pointers to their contents. Using a deque the SmallStrings will
never move around since no elements are removed from the container.
llvm-svn: 270797
Now that the string pool is referential rather than maintaining its own
copy of string data, compressed sections (well, technically only the
debug_str section*) need to be preserved for the lifetime of the pool to
match.
* I'm not currently optimizing for memory footprint with compressed
input - the major memory limit I'm hitting is on dwp+dwp merge steps
and we aren't currently compressing contents in dwp files, just in the
.dwo inputs.
llvm-svn: 270462
MC only needs to know if the output is PIC or not. It never has to
decide about creating GOTs and PLTs for example. The only thing that
MC itself uses this information for is expanding "macros" in sparc and
mips. The rest I am pretty sure could be moved to CodeGen.
This is a cleanup and isolates the code from future changes to
Reloc::Model.
llvm-svn: 269909
This diagnostic could be improved by adding the name of the input file
containing the invalid data and/or some information about how to
identify the specific offending attribute/tag in the input. But that's
not an immediate priority as these corner cases of invalid input
shouldn't come up too often.
llvm-svn: 269727
The diagnostic could be improved a bit to include information about
which input file had the mistake (& which unit (counted, since the name
of the unit won't be accessible) within the input).
llvm-svn: 269723
Actually use the error return path rather than printing the duplicate
information then a separate error. But also just tidy up/deduplicate
some of the code for generating the diagnostic text.
llvm-svn: 269692
Removed some unused headers, replaced some headers with forward class declarations.
Found using simple scripts like this one:
clear && ack --cpp -l '#include "llvm/ADT/IndexedMap.h"' | xargs grep -L 'IndexedMap[<]' | xargs grep -n --color=auto 'IndexedMap'
Patch by Eugene Kosov <claprix@yandex.ru>
Differential Revision: http://reviews.llvm.org/D19219
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 266595
Produce the first specific error message for a malformed Mach-O file describing
the problem instead of the generic message for object_error::parse_failed of
"Invalid data was encountered while parsing the file”. Many more good error
messages will follow after this first one.
This is built on Lang Hames’ great work of adding the ’Error' class for
structured error handling and threading Error through MachOObjectFile
construction. And making createMachOObjectFile return Expected<...> .
So to to get the error to the llvm-obdump tool, I changed the stack of
these methods to also return Expected<...> :
object::ObjectFile::createObjectFile()
object::SymbolicFile::createSymbolicFile()
object::createBinary()
Then finally in ParseInputMachO() in MachODump.cpp the error can
be reported and the specific error message can be printed in llvm-objdump
and can be seen in the existing test case for the existing malformed binary
but with the updated error message.
Converting these interfaces to Expected<> from ErrorOr<> does involve
touching a number of places. To contain the changes for now use of
errorToErrorCode() and errorOrToExpected() are used where the callers
are yet to be converted.
Also there some were bugs in the existing code that did not deal with the
old ErrorOr<> return values. So now with Expected<> since they must be
checked and the error handled, I added a TODO and a comment:
“// TODO: Actually report errors helpfully” and a call something like
consumeError(ObjOrErr.takeError()) so the buggy code will not crash
since needed to deal with the Error.
Note there is one fix also needed to lld/COFF/InputFiles.cpp that goes along
with this that I will commit right after this. So expect lld not to built
after this commit and before the next one.
llvm-svn: 265606
To start with, handle DW_FORM_string names. Follow up commit will handle
the interesting quirk with type units I was originally aiming for here.
llvm-svn: 265452
If you're building dwps from other dwps, it can be hard to track down a
duplicate CU ID if it comes from two compilations of the same file in
different modes, etc. By including the .dwo path (which is hopefully
more unique than the file path) it can help track down where the
duplicates came from.
llvm-svn: 264520
Going to be reading the DW_AT_GNU_dwo_name shortly as well, and there
was already enough duplication here that it was worth refactoring
rather than adding even more.
llvm-svn: 264350
These diagnostics aren't perfect - in the case of merging several dwos
into dwps and those dwps into more dwps - just getting the message about
the original source file name might not be much help (since it's the
same in both dwos, by definition - but doesn't tell you which chain of
dwps to backtrack)
It might be worth adding the DW_AT_dwo_id to the split debug info to
improve the diagnostic experience - might help track down the duplicates
better.
llvm-svn: 261988
Though a bit odd, this is handy for a few reasons - for example, in a
build system that wants consistent input/output of build steps, but
where split-dwarf might be overriden/disabled by the user on a per-file
basis.
llvm-svn: 261987
Figured this would be a problem, but didn't want to jump the gun - large
inputs demonstrate it pretty easily (mostly for type units, but might as
well do the same for CUs too). A random sample 6m27s -> 27s change.
Also, by checking this up-front for CUs (rather than when building the
cu_index) we can probably provide better error messages (see FIXMEs),
hopefully providing the name of the CUs rather than just their
signature.
llvm-svn: 261364
This avoids a operator precedence warning for mixing + and | in an
expression. I checked that this matches the definition in the Split
DWARF proposal.
Patch by Cong Liu!
Differential Revision: http://reviews.llvm.org/D17375
llvm-svn: 261207
Summary:
This patch is provided in preparation for removing autoconf on 1/26. The proposal to remove autoconf on 1/26 was discussed on the llvm-dev thread here: http://lists.llvm.org/pipermail/llvm-dev/2016-January/093875.html
"I felt a great disturbance in the [build system], as if millions of [makefiles] suddenly cried out in terror and were suddenly silenced. I fear something [amazing] has happened."
- Obi Wan Kenobi
Reviewers: chandlerc, grosbach, bob.wilson, tstellarAMD, echristo, whitequark
Subscribers: chfast, simoncook, emaste, jholewinski, tberghammer, jfb, danalbert, srhines, arsenm, dschuff, jyknight, dsanders, joker.eph, llvm-commits
Differential Revision: http://reviews.llvm.org/D16471
llvm-svn: 258861
Today, we always take into account the possibility that object files
produced by MC may be consumed by an incremental linker. This results
in us initialing fields which vary with time (TimeDateStamp) which harms
hermetic builds (e.g. verifying a self-host went well) and produces
sub-optimal code because we cannot assume anything about the relative
position of functions within a section (call sites can get redirected
through incremental linker thunks).
Let's provide an MCTargetOption which controls this behavior so that we
can disable this functionality if we know a-priori that the build will
not rely on /incremental.
llvm-svn: 256203
It's O(N^2) because it does a simple walk through the existing types to
find duplicates, but that will be fixed in a follow-up commit to use a
mapping data structure of some kind.
llvm-svn: 255482
This is a preliminary change towards deduplicating type units based on
their signatures. Next change will skip emission of types when their
signature has already been seen.
llvm-svn: 255154
Chris Bieneman