summaryrefslogtreecommitdiffstats
path: root/llvm/tools/llvm-dwp
Commit message (Collapse)AuthorAgeFilesLines
* [Mips] Use appropriate private label prefix based on Mips ABIMirko Brkusanin2019-10-231-2/+3
| | | | | | | | | | MipsMCAsmInfo was using '$' prefix for Mips32 and '.L' for Mips64 regardless of -target-abi option. By passing MCTargetOptions to MCAsmInfo we can find out Mips ABI and pick appropriate prefix. Tags: #llvm, #clang, #lldb Differential Revision: https://reviews.llvm.org/D66795
* Recommit r368812 "[llvm/Object] - Convert SectionRef::getName() to return ↵George Rimar2019-08-141-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Expected<>" Changes: no changes. A fix for the clang code will be landed right on top. Original commit message: SectionRef::getName() returns std::error_code now. Returning Expected<> instead has multiple benefits. For example, it forces user to check the error returned. Also Expected<> may keep a valuable string error message, what is more useful than having a error code. (Object\invalid.test was updated to show the new messages printed.) This patch makes a change for all users to switch to Expected<> version. Note: in a few places the error returned was ignored before my changes. In such places I left them ignored. My intention was to convert the interface used, and not to improve and/or the existent users in this patch. (Though I think this is good idea for a follow-ups to revisit such places and either remove consumeError calls or comment each of them to clarify why it is OK to have them). Differential revision: https://reviews.llvm.org/D66089 llvm-svn: 368826
* Revert r368812 "[llvm/Object] - Convert SectionRef::getName() to return ↵George Rimar2019-08-141-4/+3
| | | | | | | | Expected<>" It broke clang BB: http://lab.llvm.org:8011/builders/clang-x86_64-debian-fast/builds/16455 llvm-svn: 368813
* [llvm/Object] - Convert SectionRef::getName() to return Expected<>George Rimar2019-08-141-3/+4
| | | | | | | | | | | | | | | | | | | | | | | SectionRef::getName() returns std::error_code now. Returning Expected<> instead has multiple benefits. For example, it forces user to check the error returned. Also Expected<> may keep a valuable string error message, what is more useful than having a error code. (Object\invalid.test was updated to show the new messages printed.) This patch makes a change for all users to switch to Expected<> version. Note: in a few places the error returned was ignored before my changes. In such places I left them ignored. My intention was to convert the interface used, and not to improve and/or the existent users in this patch. (Though I think this is good idea for a follow-ups to revisit such places and either remove consumeError calls or comment each of them to clarify why it is OK to have them). Differential revision: https://reviews.llvm.org/D66089 llvm-svn: 368812
* Switch LLVM to use 64-bit offsets (2/5)Igor Kudrin2019-08-061-12/+12
| | | | | | | | | This updates all libraries and tools in LLVM Core to use 64-bit offsets which directly or indirectly come to DataExtractor. Differential Revision: https://reviews.llvm.org/D65638 llvm-svn: 368014
* Rename F_{None,Text,Append} to OF_{None,Text,Append}. NFCFangrui Song2019-08-051-1/+1
| | | | | | F_{None,Text,Append} are kept for compatibility since r334221. llvm-svn: 367800
* Fix BUILD_SHARED_LIBS builds after r361567Daniel Sanders2019-05-241-0/+2
| | | | | | Also fixed a comment I noticed while debugging this build llvm-svn: 361591
* Break false dependencies on target librariesDaniel Sanders2019-05-231-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: For the most part this consists of replacing ${LLVM_TARGETS_TO_BUILD} with some combination of AllTargets* so that they depend on specific components of a target backend rather than all of it. The overall effect of this is that, for example, tools like opt no longer falsely depend on the disassembler, while tools like llvm-ar no longer depend on the code generator. There's a couple quirks to point out here: * AllTargetsCodeGens is a bit more prevalent than expected. Tools like dsymutil seem to need it which I was surprised by. * llvm-xray linked to all the backends but doesn't seem to need any of them. It builds and passes the tests so that seems to be correct. * I left gold out as it's not built when binutils is not available so I'm unable to test it Reviewers: bogner, JDevlieghere Reviewed By: bogner Subscribers: mehdi_amini, mgorny, steven_wu, dexonsmith, rupprecht, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D62331 llvm-svn: 361567
* Recommit [Object] Change object::SectionRef::getContents() to return ↵Fangrui Song2019-05-161-3/+4
| | | | | | | | | | | | Expected<StringRef> r360876 didn't fix 2 call sites in clang. Expected<ArrayRef<uint8_t>> may be better but use Expected<StringRef> for now. Follow-up of D61781. llvm-svn: 360892
* Revert r360876 "[Object] Change object::SectionRef::getContents() to return ↵Hans Wennborg2019-05-161-4/+3
| | | | | | | | | | | | Expected<StringRef>" It broke the Clang build, see llvm-commits thread. > Expected<ArrayRef<uint8_t>> may be better but use Expected<StringRef> for now. > > Follow-up of D61781. llvm-svn: 360878
* [Object] Change object::SectionRef::getContents() to return Expected<StringRef>Fangrui Song2019-05-161-3/+4
| | | | | | | | Expected<ArrayRef<uint8_t>> may be better but use Expected<StringRef> for now. Follow-up of D61781. llvm-svn: 360876
* [llvm-dwp] Use color-formatted error reportingJordan Rupprecht2019-02-121-2/+3
| | | | llvm-svn: 353876
* [llvm-dwp] Avoid writing the output dwp file when there is an errorJordan Rupprecht2019-02-121-6/+9
| | | | | | | | | | | | | | | | Summary: Use ToolOutputFile to clean up the output file unless dwp actually finishes successfully. Reviewers: dblaikie Reviewed By: dblaikie Subscribers: jdoerfert, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D58130 llvm-svn: 353873
* [llvm-dwp] Abort when dwo_id is unsetJordan Rupprecht2019-02-121-3/+8
| | | | | | | | | | | | | | | | | | | Summary: An empty dwo_id indicates a degenerate .dwo file that should not have been generated in the first place. Instead of discovering this error later when merging with another degenerate .dwo file, print an error immediately when noticing an unset dwo_id, including the filename of the offending file. Test case created by compiling a trivial file w/ `-fno-split-dwarf-inlining -gmlt -gsplit-dwarf -c` prior to r353771 Reviewers: dblaikie Reviewed By: dblaikie Subscribers: jdoerfert, aprantl, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D58085 llvm-svn: 353846
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-192-8/+6
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* Reland rL341509: "[llvm-dwp] Use buffer_stream if output file is not ↵Fangrui Song2018-09-061-1/+9
| | | | | | | | | | seekable (e.g. "-")" It caused ambiguity between llvm::cl::Optional and llvm::Optional, which has been fixed by dropping `using namespace cl;` in favor of explicit cl:: qualified names. llvm-svn: 341586
* [llvm-dwp] Use cl:: instead of using namespace clFangrui Song2018-09-061-13/+13
| | | | | | | | | | `using namespace cl` makes llvm::cl::Optional (in Support/CommandLine.h) visible which will cause ambiguity when unqualified `Optional` is looked up (can also refer to llvm::Optional). cl:: is used much more than `using namespace cl`, so let's not use the latter. Also append \n to the argument of cl::ParseCommandLineOptions llvm-svn: 341584
* Revert rL341509 to fix massive failures on buildbotsMax Kazantsev2018-09-061-9/+1
| | | | llvm-svn: 341515
* [llvm-dwp] Use buffer_stream if output file is not seekable (e.g. "-")Fangrui Song2018-09-061-1/+9
| | | | | | | | | | Reviewers: dblaikie, pcc Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D51707 llvm-svn: 341509
* MC: Change the streamer ctors to take an object writer instead of a stream. ↵Peter Collingbourne2018-05-181-3/+4
| | | | | | | | | | | | | | NFCI. The idea is that a client that wants split dwarf would create a specific kind of object writer that creates two files, and use it to create the streamer. Part of PR37466. Differential Revision: https://reviews.llvm.org/D47050 llvm-svn: 332749
* [llvm-dwp] Define InitLLVM.Fangrui Song2018-05-061-0/+2
| | | | llvm-svn: 331610
* Rename *CommandFlags.def to *CommandFlags.incDavid Blaikie2018-04-111-1/+1
| | | | | | | | These aren't the .def style files used in LLVM that require a macro defined before their inclusion - they're just basic non-modular includes to stamp out command line flag variables. llvm-svn: 329840
* DWARF: Unify form size handling codePavel Labath2018-03-141-1/+1
| | | | | | | | | | | | | | | | | Summary: This patch replaces the two switches which are deducing the size of various forms with a single implementation. I have put the new implementation into BinaryFormat, to avoid introducing dependencies between the two independent libraries (DebugInfo and CodeGen) that need this functionality. Reviewers: aprantl, JDevlieghere, dblaikie Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D44418 llvm-svn: 327486
* Thread MCSubtargetInfo through Target::createMCAsmBackendAlex Bradbury2018-01-031-6/+6
| | | | | | | | | | | | | | | | | | | | | Currently it's not possible to access MCSubtargetInfo from a TgtMCAsmBackend. D20830 threaded an MCSubtargetInfo reference through MCAsmBackend::relaxInstruction, but this isn't the only function that would benefit from access. This patch removes the Triple and CPUString arguments from createMCAsmBackend and replaces them with MCSubtargetInfo. This patch just changes the interface without making any intentional functional changes. Once in, several cleanups are possible: * Get rid of the awkward MCSubtargetInfo handling in ARMAsmBackend * Support 16-bit instructions when valid in MipsAsmBackend::writeNopData * Get rid of the CPU string parsing in X86AsmBackend and just use a SubtargetFeature for HasNopl * Emit 16-bit nops in RISCVAsmBackend::writeNopData if the compressed instruction set extension is enabled (see D41221) This change initially exposed PR35686, which has since been resolved in r321026. Differential Revision: https://reviews.llvm.org/D41349 llvm-svn: 321692
* Remove redundant includes from tools.Michael Zolotukhin2017-12-131-9/+0
| | | | llvm-svn: 320631
* Rename MCTargetOptionsCommandFlags.h to .def as it is not a normal/modular ↵David Blaikie2017-11-271-1/+1
| | | | | | header as much as it is for stamping out some global/static variables llvm-svn: 319086
* [tools] Add option to install binutils symlinksShoaib Meenai2017-11-021-0/+4
| | | | | | | | | | | | The LLVM tools can be used as a replacement for binutils, in which case it's convenient to create symlinks with the binutils names. Add support for these symlinks in the build system. As with any other llvm tool symlinks, the user can limit the installed symlinks by only adding the desired ones to `LLVM_TOOLCHAIN_TOOLS`. Differential Revision: https://reviews.llvm.org/D39530 llvm-svn: 317272
* [MC] Have MCObjectStreamer take its MCAsmBackend argument via unique_ptr.Lang Hames2017-10-111-2/+4
| | | | | | | | MCObjectStreamer owns its MCCodeEmitter -- this fixes the types to reflect that, and allows us to remove the last instance of MCObjectStreamer's weird "holding ownership via someone else's reference" trick. llvm-svn: 315531
* [MC] Have MCObjectStreamer take its MCAsmBackend argument via unique_ptr.Lang Hames2017-10-111-2/+3
| | | | | | | | MCObjectStreamer owns its MCAsmBackend -- this fixes the types to reflect that, and allows us to remove another instance of MCObjectStreamer's weird "holding ownership via someone else's reference" trick. llvm-svn: 315410
* [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
* Don't pass the code model to MCRafael Espindola2017-08-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | I was surprised to see the code model being passed to MC. After all, it assembles code, it doesn't create it. The one place it is used is in the expansion of .cfi directives to handle .eh_frame being more that 2gb away from the code. As far as I can tell, gnu assembler doesn't even have an option to enable this. Compiling a c file with gcc -mcmodel=large produces a regular looking .eh_frame. This is probably because in practice linker parse and recreate .eh_frames. In llvm this is used because the JIT can place the code and .eh_frame very far apart. Ideally we would fix the jit and delete this option. This is hard. Apart from confusion another problem with the current interface is that most callers pass CodeModel::Default, which is bad since MC has no way to map it to the target default if it actually needed to. This patch then replaces the argument with a boolean with a default value. The vast majority of users don't ever need to look at it. In fact, only CodeGen and llvm-mc use it and llvm-mc just to enable more testing. llvm-svn: 309884
* [DWARF] NFC: Collect info used by DWARFFormValue into a helper.Paul Robinson2017-06-261-2/+2
| | | | | | | | | | | Some forms have sizes that depend on the DWARF version, DWARF format (32/64-bit), or the size of an address. Collect these into a struct to simplify passing them around. Require callers to provide one when they query a form's size. Differential Revision: http://reviews.llvm.org/D34570 llvm-svn: 306315
* [lib/Object] - Minor API update for llvm::Decompressor.George Rimar2017-05-181-1/+1
| | | | | | | | | | | | | | | | | I revisited Decompressor API (issue with it was triggered during D32865 review) and found it is probably provides more then we really need. Issue was about next method's signature: Error decompress(SmallString<32> &Out); It is too strict. At first I wanted to change it to decompress(SmallVectorImpl<char> &Out), but then found it is still not flexible because sticks to SmallVector. During reviews was suggested to use templating to simplify code. Patch do that. Differential revision: https://reviews.llvm.org/D33200 llvm-svn: 303331
* [llvm-dwp] - Reuse object::Decompressor classGeorge Rimar2017-01-131-31/+24
| | | | | | | | One more place where Decompressor class can be reused. Differential revision: https://reviews.llvm.org/D28679 llvm-svn: 291906
* [CMake] llvm-dwp depends on intrinsics_genChris Bieneman2016-11-191-0/+3
| | | | | | | | | | | | | | | | | | 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
* Clean up DWARFFormValue by reducing duplicated code and removing ↵Greg Clayton2016-11-111-2/+10
| | | | | | | | | | | | | | | | | | | | | DWARFFormValue::getFixedFormSizes() 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
* Make the Error class constructor protectedMehdi Amini2016-11-111-7/+7
| | | | | | | | | 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
* Switch all DWARF variables for tags, attributes and forms over to use the ↵Greg Clayton2016-10-271-5/+5
| | | | | | | | llvm::dwarf enumerations instead of using raw uint16_t values. This allows easier debugging as users can see the values of the enumerations in the variables view that will show the enumeration string instead of just a number. https://reviews.llvm.org/D26013 llvm-svn: 285309
* MC] Provide an MCTargetOptions to implementors of MCAsmBackendCtorTy, NFCJoel Jones2016-07-251-1/+2
| | | | | | | | | | | | | | | 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
* llvm-dwp: Ensure uncompressed sections are not relocated during processing ↵David Blaikie2016-05-251-3/+4
| | | | | | | | | | | | | | | | | | | | of later inputs 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
* llvm-dwp: Reduce indentationDavid Blaikie2016-05-231-48/+47
| | | | llvm-svn: 270507
* llvm-dwp: Split out processing of input sections to improve readabilityDavid Blaikie2016-05-231-61/+84
| | | | llvm-svn: 270503
* llvm-dwp: Pull out compression handling helperDavid Blaikie2016-05-231-15/+22
| | | | llvm-svn: 270496
* llvm-dwp: More error handling around invalid compressed sectionsDavid Blaikie2016-05-231-7/+4
| | | | llvm-svn: 270466
* llvm-dwp: Ensure compressed sections are preserved long enough for use in ↵David Blaikie2016-05-231-2/+2
| | | | | | | | | | | | | | | | the string pool 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
* llvm-dwp: Fix the build by moving DWPStringPool into the llvm namespaceDavid Blaikie2016-05-231-0/+2
| | | | llvm-svn: 270453
* llvm-dwp: Add an abstraction for the DWP string poolDavid Blaikie2016-05-233-30/+88
| | | | | | | Also reference strings in the memory mapped file, reduces memory usage on a large test case by 18.5%. llvm-svn: 270449
* Don't pass a Reloc::Model to MC.Rafael Espindola2016-05-181-1/+1
| | | | | | | | | | | | 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
* llvm-dwp: remove some unused error handlingDavid Blaikie2016-05-171-8/+5
| | | | llvm-svn: 269866
* llvm-dwp: Move error handling code closer to useDavid Blaikie2016-05-171-6/+6
| | | | llvm-svn: 269864
OpenPOWER on IntegriCloud