summaryrefslogtreecommitdiffstats
path: root/llvm/tools
Commit message (Collapse)AuthorAgeFilesLines
...
* llvm-dwarfdump: Replace -debug-dump=sect option with individual options.Adrian Prantl2017-09-112-40/+19
| | | | | | | | | | | | | | | | | | | | | | As discussed on llvm-dev in http://lists.llvm.org/pipermail/llvm-dev/2017-September/117301.html this changes the command line interface of llvm-dwarfdump to match the one used by the dwarfdump utility shipping on macOS. In addition to being shorter to type this format also has the advantage of allowing more than one section to be specified at the same time. In a nutshell, with this change $ llvm-dwarfdump --debug-dump=info $ llvm-dwarfdump --debug-dump=apple-objc becomes $ dwarfdump --debug-info --apple-objc Differential Revision: https://reviews.llvm.org/D37714 llvm-svn: 312970
* [llvm-cov] Allow hiding instantiation/region coverage from summary tablesEli Friedman2017-09-114-45/+75
| | | | | | | | | | | | | Region coverage is difficult to explain without going deep into how coverage is implemented. Instantiation coverage is easier to explain, but probably not useful in most cases (templates don't exist in C, and most C++ code contains relatively few templates). This patch adds the options "-show-region-summary" and "-show-instantiation-summary" to allow hiding those columns. "-show-instantiation-summary" is turned off by default. llvm-svn: 312969
* [llvm-cov] Don't attach exec counts to lines which start a skipped regionVedant Kumar2017-09-111-1/+7
| | | | | | | | | These lines by definition don't have an execution count. This is the final part of the fix for: https://bugs.llvm.org/show_bug.cgi?id=34166 llvm-svn: 312955
* [llvm-cov] Fix a lifetime issueVedant Kumar2017-09-087-18/+28
| | | | | | | This fixes an issue where a std::string was moved to a constructor which accepted a StringRef. llvm-svn: 312816
* [llvm-cov] Unify region marker placement between text/html modesVedant Kumar2017-09-086-24/+29
| | | | | | | | | | | | Make sure that the text and html emitters always emit the same set of region markers, and avoid emitting redundant markers for line segments which don't end on the line they start on. This is related to D35925, and depends on D36014 Differential Revision: https://reviews.llvm.org/D36020 llvm-svn: 312813
* Don't call exit from cl::PrintHelpMessage.Rafael Espindola2017-09-074-4/+8
| | | | | | | | | Most callers were not expecting the exit(0) and trying to exit with a different value. This also adds back the call to cl::PrintHelpMessage in llvm-ar. llvm-svn: 312761
* [Bitcode] Fix some Clang-tidy modernize-use-using and Include What You Use ↵Eugene Zelenko2017-09-072-11/+52
| | | | | | warnings; other minor fixes (NFC). llvm-svn: 312760
* [llvm-objcopy] Add support for special section indexes in symbol table ↵Petr Hosek2017-09-072-8/+70
| | | | | | | | | | | | | | | greater than SHN_LORESERVE As is indexes above SHN_LORESERVE will not be handled correctly because they'll be treated as indexes of sections rather than special values that should just be copied. This change adds support to copy them though. Patch by Jake Ehrlich Differential Revision: https://reviews.llvm.org/D37393 llvm-svn: 312756
* llvm-ar: exit with 1 if there is an error.Rafael Espindola2017-09-071-20/+14
| | | | | | This is pr34396. llvm-svn: 312752
* [yaml2obj][ELF] Add support for symbol indexes greater than SHN_LORESERVEPetr Hosek2017-09-071-1/+4
| | | | | | | | | | | | | Right now Symbols must be either undefined or defined in a specific section. Some symbols have section indexes like SHN_ABS however. This change adds support for outputting symbols that have such section indexes. Patch by Jake Ehrlich Differential Revision: https://reviews.llvm.org/D37391 llvm-svn: 312745
* COFF: PDB: Allow multiple modules with the same name.Peter Collingbourne2017-09-071-1/+1
| | | | | | | | | | It is possible for two modules to have the same name if they are archive members with the same name, or if we are doing LTO (in which case all modules will have the name "lto.tmp"). Differential Revision: https://reviews.llvm.org/D37589 llvm-svn: 312744
* [XRay][tools] Function call stack based analysis tooling for XRay tracesKeith Wyss2017-09-073-1/+636
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Second try after fixing a code san problem with iterator reference types. This change introduces a subcommand to the llvm-xray tool called "stacks" which allows for analysing XRay traces provided as inputs and accounting time to stacks instead of just individual functions. This gives us a more precise view of where in a program the latency is actually attributed. The tool uses a trie data structure to keep track of the caller-callee relationships as we process the XRay traces. In particular, we keep track of the function call stack as we enter functions. While we're doing this we're adding nodes in a trie and indicating a "calls" relatinship between the caller (current top of the stack) and the callee (the new top of the stack). When we push function ids onto the stack, we keep track of the timestamp (TSC) for the enter event. When exiting functions, we are able to account the duration by getting the difference between the timestamp of the exit event and the corresponding entry event in the stack. This works even if we somehow miss the exit events for intermediary functions (i.e. if the exit event is not cleanly associated with the enter event at the top of the stack). The output of the tool currently provides just the top N leaf functions that contribute the most latency, and the top N stacks that have the most frequency. In the future we can provide more sophisticated query mechanisms and potentially an export to database feature to make offline analysis of the stack traces possible with existing tools. Differential revision: D34863 llvm-svn: 312733
* Fixing incorrectly capitalised regexps.Benjamin Kramer2017-09-071-1/+1
| | | | | | Patch by Sam Allen! llvm-svn: 312709
* Reland "[llvm-objcopy] Add support for relocations"Petr Hosek2017-09-062-0/+115
| | | | | | | | | | | This change adds support for SHT_REL and SHT_RELA sections in llvm-objcopy. Patch by Jake Ehrlich Differential Revision: https://reviews.llvm.org/D36554 llvm-svn: 312680
* Revert "[llvm-objcopy] Add support for relocations"Petr Hosek2017-09-062-115/+0
| | | | | | This reverts r312643 because it's failing on llvm-i686-linux-RA. llvm-svn: 312645
* [llvm-objcopy] Add support for relocationsPetr Hosek2017-09-062-0/+115
| | | | | | | | | | | This change adds support for SHT_REL and SHT_RELA sections in llvm-objcopy. Patch by Jake Ehrlich Differential Revision: https://reviews.llvm.org/D36554 llvm-svn: 312643
* Use the section name if a STT_SECTION symbol has empty name.Rafael Espindola2017-09-061-3/+22
| | | | | | | | | | | | | Without this we would have multiple relocations pointing to symbols with the same name: the empty string. There was no way for yaml2obj to be able to handle that. A more general solution would be to unique symbol names in a similar way to how we unique section names. In practice I think this covers all common cases and is a bit more user friendly than using names like sym1, sym2, sym3, etc. llvm-svn: 312603
* Fix a use after free.Rafael Espindola2017-09-051-3/+3
| | | | llvm-svn: 312590
* obj2yaml: Print unique section names.Rafael Espindola2017-09-051-7/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | Without this patch passing a .o file with multiple sections with the same name to obj2yaml produces a yaml file that yaml2obj cannot handle. This is pr34162. The problem is that when specifying, for example, the section of a symbol, we get only Section: foo and don't know which of the sections whose name is foo we have to use. One alternative would be to use section numbers. This would work, but the output from obj2yaml would be very inconvenient to edit as deleting a section would invalidate all indexes. Another alternative would be to invent a unique section id that would exist only on yaml. This would work, but seems a bit heavy handed. We could make the id optional and default it to the section name. Since in the last alternative the id is basically what this patch uses as a name, it can be implemented as a followup patch if needed. llvm-svn: 312585
* LTO: Try to open cache files before renaming them.Peter Collingbourne2017-09-052-3/+5
| | | | | | | | | | | | | | It appears that a potential race between the cache client and the cache pruner that I thought was unlikely actually happened in practice [1]. Try to avoid the race condition by opening the temporary file before renaming it. Do this only on non-Windows platforms because we cannot rename open files on Windows using the sys::fs::rename function. [1] https://luci-logdog.appspot.com/v/?s=chromium%2Fbb%2Fchromium.memory%2FLinux_CFI%2F1610%2F%2B%2Frecipes%2Fsteps%2Fcompile%2F0%2Fstdout Differential Revision: https://reviews.llvm.org/D37410 llvm-svn: 312567
* [ORC] Refactor OrcRemoteTarget code to expose its RPC API, reduceLang Hames2017-09-041-5/+3
| | | | | | | | | | | | | | | | | | | | | | code duplication in the client, and improve error propagation. This patch moves the OrcRemoteTarget rpc::Function declarations from OrcRemoteTargetRPCAPI into their own namespaces under llvm::orc::remote so that they can be used in new contexts (in particular, a remote-object-file adapter layer that I will commit shortly). Code duplication in OrcRemoteTargetClient (especially in loops processing the code, rw-data and ro-data allocations) is removed by moving the loop bodies into their own functions. Error propagation is (slightly) improved by adding an ErrorReporter functor to the OrcRemoteTargetClient -- Errors that can't be returned (because they occur in destructors, or behind stable APIs that don't provide error returns) can be sent to the ErrorReporter instead. Some methods in the Client API are also changed to make better use of the Expected class: returning Expected<T>s rather than returning Errors and taking T&s to store the results. llvm-svn: 312500
* Revert "[XRay][tools] Function call stack based analysis tooling for XRay ↵Keith Wyss2017-09-033-636/+1
| | | | | | | | | | traces" This reverts commit 204a65e0702847a1880336372ad7abd1df414b44. Double ref qualifier failed bots. llvm-svn: 312428
* [XRay][tools] Function call stack based analysis tooling for XRay tracesKeith Wyss2017-09-033-1/+636
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change introduces a subcommand to the llvm-xray tool called "stacks" which allows for analysing XRay traces provided as inputs and accounting time to stacks instead of just individual functions. This gives us a more precise view of where in a program the latency is actually attributed. The tool uses a trie data structure to keep track of the caller-callee relationships as we process the XRay traces. In particular, we keep track of the function call stack as we enter functions. While we're doing this we're adding nodes in a trie and indicating a "calls" relatinship between the caller (current top of the stack) and the callee (the new top of the stack). When we push function ids onto the stack, we keep track of the timestamp (TSC) for the enter event. When exiting functions, we are able to account the duration by getting the difference between the timestamp of the exit event and the corresponding entry event in the stack. This works even if we somehow miss the exit events for intermediary functions (i.e. if the exit event is not cleanly associated with the enter event at the top of the stack). The output of the tool currently provides just the top N leaf functions that contribute the most latency, and the top N stacks that have the most frequency. In the future we can provide more sophisticated query mechanisms and potentially an export to database feature to make offline analysis of the stack traces possible with existing tools. llvm-svn: 312426
* Move some CLI utils out of llvm-isel-fuzzer and into the libraryJustin Bogner2017-09-022-51/+5
| | | | | | | | FuzzMutate might not be the best place for these, but it makes more sense than an entirely new library for now. This will make setting up fuzz targets with consistent CLI handling easier. llvm-svn: 312425
* [llvm-dwp] Implement -e optionAlexander Shaposhnikov2017-09-021-3/+51
| | | | | | | | | | | | | | | The binutils utility dwp has an option "-e" https://gcc.gnu.org/wiki/DebugFissionDWP to specify an executable/library to get the list of *.dwo files from it. This option is particularly useful when someone runs the tool manually outside of a build system. This diff adds an implementation of "-e" to llvm-dwp. Test plan: make check-all Differential revision: https://reviews.llvm.org/D37371 llvm-svn: 312409
* [llvm-pdbutil] Remove unused variables.Zachary Turner2017-09-021-2/+2
| | | | llvm-svn: 312395
* Fix broken test.Zachary Turner2017-09-011-2/+6
| | | | llvm-svn: 312359
* [llvm-pdbutil] Support dumping CodeView from object files.Zachary Turner2017-09-018-334/+988
| | | | | | | | | | | | | | | | | | | | | | | | We have llvm-readobj for dumping CodeView from object files, and llvm-pdbutil has always been more focused on PDB. However, llvm-pdbutil has a lot of useful options for summarizing debug information in aggregate and presenting high level statistical views. Furthermore, it's arguably better as a testing tool since we don't have to write tests to conform to a state-machine like structure where you match multiple lines in succession, each depending on a previous match. llvm-pdbutil dumps much more concisely, so it's possible to use single-line matches in many cases where as with readobj tests you have to use multi-line matches with an implicit state machine. Because of this, I'm adding object file support to llvm-pdbutil. In fact, this mirrors the cvdump tool from Microsoft, which also supports both object files and pdb files. In the future we could perhaps rename this tool llvm-cvutil. In the meantime, this allows us to deep dive into object files the same way we already can with PDB files. llvm-svn: 312358
* llvm-isel-fuzzer: Weak function invoke the ire of PE/COFFJustin Bogner2017-09-011-4/+1
| | | | | | | | | | | | | | | It's non-trivial to use weak symbols in a cross platform way (See sanitizer_win_defs.h in compiler-rt), and doing it naively like we have here causes some build failures: http://lab.llvm.org:8011/builders/clang-with-thin-lto-windows/builds/1260 Instead of going down the rabbit hole of emulating weak symbols for this very trivial dummy fuzzer driver, we can just rely on the fact that we know which hooks any given fuzz target implements and forward declare a normal symbol. llvm-svn: 312354
* llvm-isel-fuzzer: Add link-time dependency on BitWriterJustin Bogner2017-09-011-0/+1
| | | | | | | | | | This should fix the undefined reference to WriteBitcodeToFile here: http://bb.pgr.jp/builders/i686-mingw32-RA-on-linux/builds/31682 (Why does every different bot seem to have a different level of finickiness about LLVM_LINK_COMPONENTS?) llvm-svn: 312345
* llvm-isel-fuzzer: Add link-time dependency on BitReaderJustin Bogner2017-09-011-0/+1
| | | | | | | This should fix the undefined reference to parseBitcodeFile here: http://bb.pgr.jp/builders/llvm-i686-linux-RA/builds/5785 llvm-svn: 312343
* [WebAssembly] Update relocation names to match specSam Clegg2017-09-012-6/+6
| | | | | | | | Summary: See https://github.com/WebAssembly/tool-conventions/blob/master/Linking.md Differential Revision: https://reviews.llvm.org/D37385 llvm-svn: 312342
* Specify the namespace in llvm::make_unique to fix the windows buildJustin Bogner2017-09-011-1/+1
| | | | llvm-svn: 312341
* llvm-isel-fuzzer: Make buildable and testable without libFuzzerJustin Bogner2017-09-012-1/+58
| | | | | | | | | | | | | | This adds a dummy main so we can build and run the llvm-isel-fuzzer functionality when we aren't building LLVM with coverage. The approach here should serve as a template to stop in-tree fuzzers from bitrotting (See llvm.org/pr34314). Note that I'll probably move most of the logic in DummyISelFuzzer's `main` to a library so it's easy to reuse it in other fuzz targets, but I'm planning on doing that in a follow up that also consolidates argument handling in our LLVMFuzzerInitialize implementations. llvm-svn: 312338
* Fix check-llvm on kernel 4.9+ with asan or msanVitaly Buka2017-09-011-4/+10
| | | | | | | | | | | | | | Summary: Before https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?h=v4.9.46&id=84638335900f1995495838fe1bd4870c43ec1f67 test worked because memory allocated with mmap was not counted against RLIMIT_DATA. Reviewers: eugenis Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D37366 llvm-svn: 312303
* [Analysis] Fix some Clang-tidy modernize-use-using and Include What You Use ↵Eugene Zelenko2017-08-313-52/+98
| | | | | | warnings; other minor fixes. Also affected in files (NFC). llvm-svn: 312289
* [llvm-nm] Fix output formatting of -f sysv for 64bit targetsSam Clegg2017-08-311-3/+7
| | | | | | Differential Revision: https://reviews.llvm.org/D37347 llvm-svn: 312284
* Fix some size_t / uint32_t mismatched comparisons.Zachary Turner2017-08-311-4/+4
| | | | llvm-svn: 312278
* [llvm-pdbutil] Print detailed S_UDT stats.Zachary Turner2017-08-317-33/+197
| | | | | | | | | | | | | | This adds a new command line option, -udt-stats, which breaks down the stats of S_UDT records. These are one of the biggest contributors to the size of /DEBUG:FASTLINK PDBs, so they need some additional tools to be able to analyze their usage. This option will dig into each S_UDT record and determine what kind of record it points to, and then break down the statistics by the target type. The goal here is to identify how our object files differ from MSVC object files in S_UDT records, so that we can output fewer of them and reach size parity. llvm-svn: 312276
* [dsymutil] Don't mark forward declarations as canonical.Jonas Devlieghere2017-08-311-17/+45
| | | | | | | | | | | | | | | | | | This patch completes the work done by Frederic Riss to addresses dsymutil incorrectly considering forward declaration as canonical during uniquing. This resulted in references to the forward declaration even after the definition was encountered. In addition to the test provided by Alexander Shaposhnikov in D29609, I added another test to cover several scenarios that were mentioned in his conversation with Fred. We now also check that uniquing still occurs after the definition was encountered. For more context please refer to D29609 Differential revision: https://reviews.llvm.org/D37127 llvm-svn: 312274
* Revert "[dsymutil] Don't mark forward declarations as canonical."Jonas Devlieghere2017-08-311-45/+17
| | | | | | This reverts commit r312264. llvm-svn: 312271
* [dsymutil] Don't mark forward declarations as canonical.Jonas Devlieghere2017-08-311-17/+45
| | | | | | | | | | | | | | | | | | This patch completes the work done by Frederic Riss to addresses dsymutil incorrectly considering forward declaration as canonical during uniquing. This resulted in references to the forward declaration even after the definition was encountered. In addition to the test provided by Alexander Shaposhnikov in D29609, I added another test to cover several scenarios that were mentioned in his conversation with Fred. We now also check that uniquing still occurs after the definition was encountered. For more context please refer to D29609 Differential revision: https://reviews.llvm.org/D37127 llvm-svn: 312264
* [llvm-dwarfdump] Brief mode only dumps debug_info by defaultJonas Devlieghere2017-08-311-3/+12
| | | | | | | | | | | | This patch changes the default behavior in brief mode to only show the debug_info section. This is undoubtedly the most popular and likely the one you'd want in brief mode. Non-brief mode behavior is not affected and still defaults to all. Differential revision: https://reviews.llvm.org/D37334 llvm-svn: 312252
* [llvm-cov] Read in function names for filtering from a text file.Sean Eveson2017-08-313-1/+40
| | | | | | | | | | | | | | Summary: Add a -name-whitelist option, which behaves in the same way as -name, but it reads in multiple function names from the given input file(s). Reviewers: vsk Reviewed By: vsk Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D37111 llvm-svn: 312227
* [XRay][tools] Fix an accounting bug in llvm-xray accountDean Michael Berris2017-08-311-3/+31
| | | | | | | | | | | | | | | | | | Summary: Before this patch, llvm-xray account will assume that thread stacks will not be empty. Unfortunately there are cases where an instrumented function will see a call to `fork()` which will cause the child process to not see the start of the function, but only see the end of the function. The tooling cannot assume that threads will always have perfect stacks, and so we change it to support this reality. Reviewers: dblaikie Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D31870 llvm-svn: 312204
* cmake: Invent add_llvm_fuzzer to set up fuzzer targetsJustin Bogner2017-08-316-70/+45
| | | | | | | | | | | | | | | | This moves the cmake configuration for fuzzers in LLVM to a new macro, add_llvm_fuzzer. This will make it easier to keep things consistent while implementing llvm.org/pr34314. I've also made a couple of minor functional changes here: - the fuzzers now use add_llvm_executable rather than add_llvm_tool. This means they won't create install targets and stuff like that, because those made little sense for these fuzzers. - I've grouped these under "Fuzzers" rather than in with "Tools" for people who build with IDEs. llvm-svn: 312200
* llvm-isel-fuzzer: Stop including FuzzerInterface.hJustin Bogner2017-08-312-3/+0
| | | | | | | | | All this does is forward declare the interface functions (and make sure that they're `extern "C"`), but since we're using libFuzzer from the toolchain it doesn't make sense to include the local copy of the interface. llvm-svn: 312195
* [yaml2obj][ELF] Make symbols optional for relocationsPetr Hosek2017-08-301-1/+2
| | | | | | | | | | | | | | | | Some kinds of relocations do not have symbols, like R_X86_64_RELATIVE for instance. I would like to test this case in D36554 but currently can't because symbols are required by yaml2obj. The other option is using the empty symbol but that doesn't seem quite right to me. This change makes the Symbol field of Relocation optional and in the case where the user does not specify a symbol name the Symbol index is 0. Patch by Jake Ehrlich Differential Revision: https://reviews.llvm.org/D37276 llvm-svn: 312192
* Simplify writeArchive return type.Rui Ueyama2017-08-301-2/+2
| | | | | | | | | | writeArchive returned a pair, but the first element of the pair is always its first argument on failure, so it doesn't make sense to return it from the function. This patch change the return type so that it does't return it. Differential Revision: https://reviews.llvm.org/D37313 llvm-svn: 312177
* [dwarfdump] Pretty print location expressions and location listsReid Kleckner2017-08-292-1/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Based on Fred's patch here: https://reviews.llvm.org/D6771 I can't seem to commandeer the old review, so I'm creating a new one. With that change the locations exrpessions are pretty printed inline in the DIE tree. The output looks like this for debug_loc entries: DW_AT_location [DW_FORM_data4] (0x00000000 0x0000000000000001 - 0x000000000000000b: DW_OP_consts +3 0x000000000000000b - 0x0000000000000012: DW_OP_consts +7 0x0000000000000012 - 0x000000000000001b: DW_OP_reg0 RAX, DW_OP_piece 0x4 0x000000000000001b - 0x0000000000000024: DW_OP_breg5 RDI+0) And like this for debug_loc.dwo entries: DW_AT_location [DW_FORM_sec_offset] (0x00000000 Addr idx 2 (w/ length 190): DW_OP_consts +0, DW_OP_stack_value Addr idx 3 (w/ length 23): DW_OP_reg0 RAX, DW_OP_piece 0x4) Simple locations without ranges are printed inline: DW_AT_location [DW_FORM_block1] (DW_OP_reg4 RSI, DW_OP_piece 0x4, DW_OP_bit_piece 0x20 0x0) The debug_loc(.dwo) dumping in changed accordingly to factor the code. Reviewers: dblaikie, aprantl, friss Subscribers: mgorny, javed.absar, hiraditya, llvm-commits, JDevlieghere Differential Revision: https://reviews.llvm.org/D37123 llvm-svn: 312042
OpenPOWER on IntegriCloud