summaryrefslogtreecommitdiffstats
path: root/llvm/tools/llvm-dwp
Commit message (Collapse)AuthorAgeFilesLines
...
* llvm-dwp: Add error handling for multiple type sections in a dwp file.David Blaikie2016-05-171-1/+3
| | | | llvm-svn: 269851
* llvm-dwp: Simplify duplicate DWO ID error handlingDavid Blaikie2016-05-171-9/+9
| | | | llvm-svn: 269805
* llvm-dwp: Provide error handling for invalid string field formsDavid Blaikie2016-05-171-8/+16
| | | | | | | | | | 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
* llvm-dwp: Add error handling for invalid (non-CU) top level tag in ↵David Blaikie2016-05-161-8/+14
| | | | | | | | | | debug_info.dwo 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
* llvm-dwp: Streamline duplicate DWO ID diagnostic handlingDavid Blaikie2016-05-161-24/+27
| | | | | | | | 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
* llvm-dwp: Use llvm::Error to improve diagnostic quality/error handling in ↵David Blaikie2016-05-124-20/+45
| | | | | | llvm-dwp llvm-svn: 269339
* [NFC] Header cleanupMehdi Amini2016-04-181-2/+0
| | | | | | | | | | | | | | 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
* llvm-dwp: Add assert textDavid Blaikie2016-04-131-1/+3
| | | | | | Post-commit feedback from Eric Christopher on r265452. llvm-svn: 266225
* Thread Expected<...> up from createMachOObjectFile() to allow llvm-objdump ↵Kevin Enderby2016-04-061-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | to produce a real error message 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
* llvm-dwp: Handle GCC's use of multiple debug_types.dwo sections in a single ↵David Blaikie2016-04-051-31/+32
| | | | | | | | .dwo file (also includes the .test file missing from my previous commit, r265452) llvm-svn: 265457
* llvm-dwp: Handle dwo files produced by GCCDavid Blaikie2016-04-051-4/+8
| | | | | | | 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
* llvm-dwp: Simplify hashing code a bitDavid Blaikie2016-04-051-1/+2
| | | | llvm-svn: 265426
* llvm-dwp: Include the dwo name (if available) when diagnosing duplicate CU ↵David Blaikie2016-03-261-20/+41
| | | | | | | | | | | | IDs from dwp input files 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
* llvm-dwp: Coalesce code for reading the CU's DW_AT_GNU_dwo_id and DW_AT_nameDavid Blaikie2016-03-241-51/+36
| | | | | | | | 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
* llvm-dwp: Add missing copyright notice to llvm-dwp.cppDavid Blaikie2016-03-011-0/+13
| | | | | | Addressing feedback on IRC by Sean Silva. llvm-svn: 262416
* Revert "llvm-dwp: Keep ObjectFiles alive until object emission their ↵David Blaikie2016-03-011-10/+8
| | | | | | | | | | contents can be referenced directly rather than copied" Accidentally committed. This reverts commit r262389. llvm-svn: 262395
* llvm-dwp: Keep ObjectFiles alive until object emission their contents can be ↵David Blaikie2016-03-011-8/+10
| | | | | | referenced directly rather than copied llvm-svn: 262389
* llvm-dwp: provide diagnostics for duplicate DWO IDsDavid Blaikie2016-02-261-3/+75
| | | | | | | | | | | | | | 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
* llvm-dwp: Support empty .dwo filesDavid Blaikie2016-02-261-9/+11
| | | | | | | | | 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
* llvm-dwp: Improve performance (N^2 to amortized N) by using a MapVector ↵David Blaikie2016-02-191-39/+35
| | | | | | | | | | | | | | | instead of linear searches through a vector 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
* llvm-dwp: Don't test compression when zlib isn't availableDavid Blaikie2016-02-191-1/+1
| | | | llvm-svn: 261298
* llvm-dwp: Support compressed inputDavid Blaikie2016-02-191-5/+45
| | | | llvm-svn: 261296
* Add parentheses around arithmetic in operand of '|'.Benjamin Kramer2016-02-181-1/+1
| | | | | | | | | | | | 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
* llvm-dwp: Support for type units when merging DWPs into larger DWPsDavid Blaikie2016-02-171-2/+54
| | | | llvm-svn: 261072
* Fix the hash function.David Blaikie2016-02-171-1/+1
| | | | llvm-svn: 261071
* [llvm-dwp] Merge cu_index from DWPsDavid Blaikie2016-02-061-6/+37
| | | | | | This is almost feature complete - just missing tu_index merging now. llvm-svn: 259971
* Remove autoconf supportChris Bieneman2016-01-261-18/+0
| | | | | | | | | | | | | | | | 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
* [MC, COFF] Support link /incremental conditionallyDavid Majnemer2015-12-211-1/+4
| | | | | | | | | | | | | | | | 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
* [llvm-dwp] Deduplicate type unitsDavid Blaikie2015-12-141-6/+12
| | | | | | | | 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
* [llvm-dwp] Sink debug_types.dwo emission into the code parsing the type ↵David Blaikie2015-12-091-15/+27
| | | | | | | | | | signatures (NFC) 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
* [llvm-dwp] Add coverage for both the presence and absence of type units, and ↵David Blaikie2015-12-051-5/+7
| | | | | | fix/remove the emission of a broken tu_index when no type units are present llvm-svn: 254833
* [llvm-dwp] clang-format this to catch anything I've missed along the wayDavid Blaikie2015-12-051-12/+13
| | | | llvm-svn: 254828
* [llvm-dwp] Support debug_tu_indexDavid Blaikie2015-12-051-53/+110
| | | | llvm-svn: 254827
* [llvm-dwp] Implement the required on-disk probed hash tableDavid Blaikie2015-12-041-5/+16
| | | | llvm-svn: 254770
* [llvm-dwp] Include the debug_line.dwo sectionDavid Blaikie2015-12-041-0/+1
| | | | | | | | | | | | This probably shouldn't be generated in the .dwo file for CUs, only for TUs, but it's in the sample .dwos (generated by clang) so dwp should reflect that. Arguably the DWP tool could be smart enough to know that the CUs shouldn't need a debug_line.dwo section and skip that even when it's legitimately generated for TUs, but that's a bit more off-book. llvm-svn: 254767
* [llvm-dwp] Retrieve the DWOID from the CU for the cu_index entryDavid Blaikie2015-12-041-2/+61
| | | | llvm-svn: 254731
* [llvm-dwp] Include only the non-empty columns in the cu_indexDavid Blaikie2015-12-021-7/+15
| | | | llvm-svn: 254555
* [llvm-dwp] Emit a rather fictional debug_cu_indexDavid Blaikie2015-12-021-22/+81
| | | | | | | | | | | | | | This is very rudimentary support for debug_cu_index, but it is enough to allow llvm-dwarfdump to find the offsets for contributions and correctly dump debug_info. It will need to actually find the real signature of the unit and build the real hash table with the right number of buckets, as per the DWP specification. It will also need to be expanded to cover the tu_index as well. llvm-svn: 254489
* [llvm-dwp] Deduplicate strings in the debug_str.dwo sectionDavid Blaikie2015-12-011-14/+20
| | | | | | | Also, ensure that references to those strings in debug_str_offsets.dwo correctly refer to the deduplicated strings. llvm-svn: 254441
* [llvm-dwp] Correctly update debug_str_offsets.dwo when linking dwo filesDavid Blaikie2015-12-011-17/+68
| | | | | | | | | | This doesn't deduplicate strings in the debug_str section, nor does it properly wire up the index so that debug_info can /find/ these strings, but it does correct the str_offsets specifically. Follow up patches to address those related/next issues. llvm-svn: 254431
* [llvm-dwp] Add missing Makefile for the old configure+make buildDavid Blaikie2015-12-011-0/+18
| | | | llvm-svn: 254358
* [llvm-dwp] Initial partial prototypeDavid Blaikie2015-12-011-1/+143
| | | | | | | | | | | | | | | | | | | This just concatenates the common DWP sections without doing any of the fancy DWP things like: 1) update str_offsets 2) deduplicating strings 3) merging/creating cu/tu_index Patches for these will follow shortly. (also not sure about target triple/object file type for this tool - do I really need a whole triple just to write an object file that contains purely static/hardcoded bytes in each section? & I guess I should just pick it based on the first input, maybe, rather than hardcoding for now - but we only produce .dwo on ELF platforms with objcopy for now anyway) llvm-svn: 254355
* llvm-dwp: Initial layoutDavid Blaikie2015-12-013-0/+38
llvm-svn: 254354
OpenPOWER on IntegriCloud