Skip to content
  1. Jun 17, 2020
  2. Feb 10, 2020
  3. Jan 28, 2020
    • Benjamin Kramer's avatar
      Make llvm::StringRef to std::string conversions explicit. · adcd0268
      Benjamin Kramer authored
      This is how it should've been and brings it more in line with
      std::string_view. There should be no functional change here.
      
      This is mostly mechanical from a custom clang-tidy check, with a lot of
      manual fixups. It uncovers a lot of minor inefficiencies.
      
      This doesn't actually modify StringRef yet, I'll do that in a follow-up.
      adcd0268
  4. Jan 11, 2020
    • Fangrui Song's avatar
      [Disassembler] Delete the VStream parameter of MCDisassembler::getInstruction() · 6fdd6a7b
      Fangrui Song authored
      The argument is llvm::null() everywhere except llvm::errs() in
      llvm-objdump in -DLLVM_ENABLE_ASSERTIONS=On builds. It is used by no
      target but X86 in -DLLVM_ENABLE_ASSERTIONS=On builds.
      
      If we ever have the needs to add verbose log to disassemblers, we can
      record log with a member function, instead of passing it around as an
      argument.
      6fdd6a7b
  5. Jan 07, 2020
    • Fangrui Song's avatar
      [MC] Add parameter `Address` to MCInstPrinter::printInst · aa708763
      Fangrui Song authored
      printInst prints a branch/call instruction as `b offset` (there are many
      variants on various targets) instead of `b address`.
      
      It is a convention to use address instead of offset in most external
      symbolizers/disassemblers. This difference makes `llvm-objdump -d`
      output unsatisfactory.
      
      Add `uint64_t Address` to printInst(), so that it can pass the argument to
      printInstruction(). `raw_ostream &OS` is moved to the last to be
      consistent with other print* methods.
      
      The next step is to pass `Address` to printInstruction() (generated by
      tablegen from the instruction set description). We can gradually migrate
      targets to print addresses instead of offsets.
      
      In any case, downstream projects which don't know `Address` can pass 0 as
      the argument.
      
      Reviewed By: jhenderson
      
      Differential Revision: https://reviews.llvm.org/D72172
      aa708763
  6. Oct 23, 2019
  7. Aug 15, 2019
  8. Aug 14, 2019
    • George Rimar's avatar
      Recommit r368812 "[llvm/Object] - Convert SectionRef::getName() to return Expected<>" · bcc00e1a
      George Rimar authored
      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
      bcc00e1a
    • George Rimar's avatar
    • George Rimar's avatar
      [llvm/Object] - Convert SectionRef::getName() to return Expected<> · a0c6a357
      George Rimar authored
      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
      a0c6a357
  9. Aug 05, 2019
  10. Aug 04, 2019
  11. Jul 30, 2019
  12. May 16, 2019
  13. Apr 24, 2019
  14. Feb 27, 2019
    • Alexey Lapshin's avatar
      [DebugInfo] add SectionedAddress to DebugInfo interfaces. · 77fc1f60
      Alexey Lapshin authored
            That patch is the fix for https://bugs.llvm.org/show_bug.cgi?id=40703
         "wrong line number info for obj file compiled with -ffunction-sections"
         bug. The problem happened with only .o files. If object file contains
         several .text sections then line number information showed incorrectly.
         The reason for this is that DwarfLineTable could not detect section which
         corresponds to specified address(because address is the local to the
         section). And as the result it could not select proper sequence in the
         line table. The fix is to pass SectionIndex with the address. So that it
         would be possible to differentiate addresses from various sections. With
         this fix llvm-objdump shows correct line numbers for disassembled code.
      
         Differential review: https://reviews.llvm.org/D58194
      
      llvm-svn: 354972
      77fc1f60
  15. Jan 19, 2019
    • Chandler Carruth's avatar
      Update the file headers across all of the LLVM projects in the monorepo · 2946cd70
      Chandler Carruth authored
      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
      2946cd70
  16. Sep 15, 2018
  17. Sep 13, 2018
  18. Aug 24, 2018
    • Joel Galenson's avatar
      [cfi-verify] Support cross-DSO · 6cc0e63e
      Joel Galenson authored
      When used in cross-DSO mode, CFI will generate calls to special functions rather than trap instructions.  For example, instead of generating
      
      if (!InlinedFastCheck(f))
        abort();
      call *f
      
      CFI generates
      
      if (!InlinedFastCheck(f))
        __cfi_slowpath(CallSiteTypeId, f);
      call *f
      
      This patch teaches cfi-verify to recognize calls to __cfi_slowpath and abort and treat them as trap functions.
      
      In addition to normal symbols, we also parse the dynamic relocations to handle cross-DSO calls in libraries.
      
      We also extend cfi-verify to recognize other patterns that occur using cross-DSO.  For example, some indirect calls are not guarded by a branch to a trap but instead follow a call to __cfi_slowpath.  For example:
      
      if (!InlinedFastCheck(f))
        call *f
      else {
        __cfi_slowpath(CallSiteTypeId, f);
        call *f
      }
      
      In this case, the second call to f is not marked as protected by the current code.  We thus recognize if indirect calls directly follow a call to a function that will trap on CFI violations and treat them as protected.
      
      We also ignore indirect calls in the PLT, since on AArch64 each entry contains an indirect call that should not be protected by CFI, and these are labeled incorrectly when debug information is not present.
      
      Differential Revision: https://reviews.llvm.org/D49383
      
      llvm-svn: 340612
      6cc0e63e
  19. Jul 16, 2018
  20. Jul 13, 2018
    • Joel Galenson's avatar
      [cfi-verify] Support AArch64. · 06e7e579
      Joel Galenson authored
      This patch adds support for AArch64 to cfi-verify.
      
      This required three changes to cfi-verify.  First, it generalizes checking if an instruction is a trap by adding a new isTrap flag to TableGen (and defining it for x86 and AArch64).  Second, the code that ensures that the operand register is not clobbered between the CFI check and the indirect call needs to allow a single dereference (in x86 this happens as part of the jump instruction).  Third, we needed to ensure that return instructions are not counted as indirect branches.  Technically, returns are indirect branches and can be covered by CFI, but LLVM's forward-edge CFI does not protect them, and x86 does not consider them, so we keep that behavior.
      
      In addition, we had to improve AArch64's code to evaluate the branch target of a MCInst to handle calls where the destination is not the first operand (which it often is not).
      
      Differential Revision: https://reviews.llvm.org/D48836
      
      llvm-svn: 337007
      06e7e579
  21. May 09, 2018
  22. Dec 13, 2017
  23. Nov 15, 2017
  24. Nov 14, 2017
    • Mitch Phillips's avatar
      [cfi-verify] Add DOT graph printing for GraphResult objects. · 02993892
      Mitch Phillips authored
      Allows users to view GraphResult objects in a DOT directed-graph format. This feature can be turned on through the --print-graphs flag.
      
      Also enabled pretty-printing of instructions in output. Together these features make analysis of unprotected CF instructions much easier by providing a visual control flow graph.
      
      Reviewers: pcc
      
      Subscribers: llvm-commits, kcc, vlad.tsyrklevich
      
      Differential Revision: https://reviews.llvm.org/D39819
      
      llvm-svn: 318211
      02993892
  25. Nov 10, 2017
    • Mitch Phillips's avatar
      [cfi-verify] Made FileAnalysis operate on a GraphResult rather than build one and validate it. · 3b9ea32e
      Mitch Phillips authored
      Refactors the behaviour of building graphs out of FileAnalysis, allowing for analysis of the GraphResult by the callee without having to rebuild the graph. Means when we want to analyse the constructed graph (planned for later revisions), we don't do repeated work.
      
      Also makes CFI verification in FileAnalysis now return an enum that allows us to differentiate why something failed, not just that it did/didn't fail.
      
      Reviewers: vlad.tsyrklevich
      
      Subscribers: kcc, pcc, llvm-commits
      
      Differential Revision: https://reviews.llvm.org/D39764
      
      llvm-svn: 317927
      3b9ea32e
  26. Nov 09, 2017
    • Mitch Phillips's avatar
      [cfi-verify] Adds blacklist blame behaviour to cfi-verify. · d64af525
      Mitch Phillips authored
      Adds the blacklist behaviour to llvm-cfi-verify. Now will calculate which lines caused expected failures in the blacklist and reports the number of affected indirect CF instructions for each blacklist entry.
      
      Also moved DWARF checking after instruction analysis to improve performance significantly - unrolling the inlining stack is expensive.
      
      Reviewers: vlad.tsyrklevich
      
      Subscribers: aprantl, pcc, kcc, llvm-commits
      
      Differential Revision: https://reviews.llvm.org/D39750
      
      llvm-svn: 317743
      d64af525
  27. Nov 04, 2017
  28. Nov 03, 2017
    • Mitch Phillips's avatar
      [cfi-verify] Add blacklist parsing for result filtering. · c15bdf55
      Mitch Phillips authored
      Adds blacklist parsing behaviour for filtering results into four categories:
      
       - Expected Protected: Things that are not in the blacklist and are protected.
       - Unexpected Protected: Things that are in the blacklist and are protected.
       - Expected Unprotected: Things that are in the blacklist and are unprotected.
       - Unexpected Unprotected: Things that are not in the blacklist and are unprotected.
      
       now can optionally be invoked with a second command line argument, which specifies the blacklist file that the binary was built with.
      
      Current  statistics for chromium:
      
      Reviewers: vlad.tsyrklevich
      
      Subscribers: mgorny, llvm-commits, pcc, kcc
      
      Differential Revision: https://reviews.llvm.org/D39525
      
      llvm-svn: 317364
      c15bdf55
  29. Nov 02, 2017
  30. Nov 01, 2017
    • Mitch Phillips's avatar
      Parse DWARF information to reduce false positives. · 7db6f7a3
      Mitch Phillips authored
      Summary: Help differentiate code and data by parsing DWARF information. This will reduce false positive rates where data is placed in executable sections and is mistakenly parsed as code, resulting in an inflation in the number of indirect CF instructions (and hence an inflation of the number of unprotected).
      
      Also prints the DWARF line data around the region of each indirect CF instruction.
      
      Reviewers: pcc
      
      Subscribers: probinson, llvm-commits, vlad.tsyrklevich, mgorny, aprantl, kcc
      
      Differential Revision: https://reviews.llvm.org/D38654
      
      llvm-svn: 317050
      7db6f7a3
  31. Oct 25, 2017
    • Mitch Phillips's avatar
      Add FileVerifier::isCFIProtected(). · 5ff01cdc
      Mitch Phillips authored
      Add a CFI protection check that is implemented by building a graph and inspecting the output to deduce if the indirect CF instruction is CFI protected. Also added the output of this instruction to printIndirectInstructions().
      
      Reviewers: vlad.tsyrklevich
      
      Subscribers: llvm-commits, kcc, pcc, mgorny
      
      Differential Revision: https://reviews.llvm.org/D38428
      
      llvm-svn: 316610
      5ff01cdc
  32. Oct 23, 2017
Loading