1. 03 Feb, 2021 4 commits
  2. 21 Jan, 2021 1 commit
  3. 12 Jan, 2021 2 commits
  4. 18 Dec, 2020 2 commits
  5. 17 Dec, 2020 2 commits
    • Jonas Hahnfeld's avatar
      [CMake] Avoid __FakeVCSRevision.h with no git repository · d104e582
      Jonas Hahnfeld authored
      Set the return variable to "" in find_first_existing_vc_file to
      say that there is a repository, but no file to depend on. This works
      transparently for all other callers that handle undefinedness and
      equality to an empty string the same way.
      
      Use the knowledge to avoid depending on __FakeVCSRevision.h if there
      is no git repository at all (for example when building a release) as
      there is no point in regenerating an empty VCSRevision.h.
      
      Differential Revision: https://reviews.llvm.org/D92718
      
      (cherry picked from commit 6e890ec7)
      d104e582
    • James Henderson's avatar
      Don't error for zero-length arange entries · f5f8d86d
      James Henderson authored
      Although the DWARF specification states that .debug_aranges entries
      can't have length zero, these can occur in the wild. There's no
      particular reason to enforce this part of the spec, since functionally
      they have no impact. The patch removes the error and introduces a new
      warning for premature terminator entries which does not stop parsing.
      
      This is a relanding of cb3a598c, adding the missing obj2yaml part
      that was needed.
      
      Fixes https://bugs.llvm.org/show_bug.cgi?id=46805. See also
      https://reviews.llvm.org/D71932 which originally introduced the error.
      
      Reviewed by: ikudrin, dblaikie, Higuoxing
      
      Differential Revision: https://reviews.llvm.org/D85313
      f5f8d86d
  6. 16 Dec, 2020 4 commits
    • Jessica Paquette's avatar
      [AArch64][GlobalISel] Narrow 128-bit regs to 64-bit regs in emitTestBit · 280e47ea
      Jessica Paquette authored
      When we have a 128-bit register, emitTestBit would incorrectly narrow to 32
      bits always. If the bit number was > 32, then we would need a TB(N)ZX. This
      would cause a crash, as we'd have the wrong register class. (PR48379)
      
      This generalizes `narrowExtReg` into `moveScalarRegClass`.
      
      This also allows us to remove `widenGPRBankRegIfNeeded` entirely, since
      `selectCopy` correctly handles SUBREG_TO_REG etc.
      
      This does create some codegen changes (since `selectCopy` uses the `all`
      regclass variants). However, I think that these will likely be optimized away,
      and we can always improve the `selectCopy` code. It looks like we should
      revisit `selectCopy` at this point, and possibly refactor it into at least one
      `emit` function.
      
      Differential Revision: https://reviews.llvm.org/D92707
      
      (cherry picked from commit 195a7af0)
      280e47ea
    • Amara Emerson's avatar
      [AArch64][GlobalISel] Look through a G_ZEXT when trying to match shift-extended register offsets. · 9e16c5bf
      Amara Emerson authored
      The G_ZEXT in these cases seems to actually come from a combine that we do but
      SelectionDAG doesn't. Looking through it allows us to match "uxtw #2" addressing
      modes.
      
      Differential Revision: https://reviews.llvm.org/D91475
      
      (cherry picked from commit 0b609069)
      9e16c5bf
    • Ronald Wampler's avatar
      [Support] PR42623: Avoid setting the delete-on-close bit if a TempFile doesn't... · 6ec777c2
      Ronald Wampler authored
      [Support] PR42623: Avoid setting the delete-on-close bit if a TempFile doesn't reside on a local drive
      
      On Windows, after commit 881ba104, tools
      using TempFile would error with "bad file descriptor" when writing the
      file on a network drive. It appears that setting the delete-on-close bit via
      SetFileInformationByHandle/FileDispositionInfo prevented it from
      accessing the file on network drives, and although using
      FILE_DISPOSITION_INFO seems to work, it causes other troubles.
      
      Differential Revision: https://reviews.llvm.org/D81803
      
      (cherry picked from commit 79657e23)
      6ec777c2
    • Aleksandr Platonov's avatar
      [Support][Windows] Fix incorrect GetFinalPathNameByHandleW() return value... · f684355e
      Aleksandr Platonov authored
      [Support][Windows] Fix incorrect GetFinalPathNameByHandleW() return value check in realPathFromHandle()
      
      `GetFinalPathNameByHandleW(,,N,)` returns:
      - `< N` on success (this value does not include the size of the terminating null character)
      - `>= N` if buffer is too small (this value includes the size of the terminating null character)
      
      So, when `N == Buffer.capacity() - 1`, we need to resize buffer if return value is > `Buffer.capacity() - 2`.
      Also, we can set `N` to `Buffer.capacity()`.
      
      Thus, without this patch `realPathFromHandle()` returns unfilled buffer when length of the final path of the file is equal to `Buffer.capacity()` or `Buffer.capacity() - 1`.
      
      Reviewed By: andrewng, amccarth
      
      Differential Revision: https://reviews.llvm.org/D86564
      
      (cherry picked from commit ceffd699)
      f684355e
  7. 15 Dec, 2020 5 commits
    • Richard Smith's avatar
      Don't reject calls to MinGW's unusual _setjmp declaration. · 98f575ff
      Richard Smith authored
      We now recognize this function as a builtin despite it having an
      unexpected number of parameters; make sure we don't enforce that it has
      only 1 argument for its 2 parameters.
      98f575ff
    • Richard Smith's avatar
      Recognize setjmp and friends as builtins even if jmp_buf is not declared yet. · 0312bec0
      Richard Smith authored
      This happens in glibc's headers. It's important that we recognize these
      functions so that we can mark them as returns_twice.
      
      Differential Revision: https://reviews.llvm.org/D88518
      0312bec0
    • Raul Tambre's avatar
      [Sema] Handle objc_super special lookup when checking builtin compatibility · fdab7563
      Raul Tambre authored
      objc_super is special and needs LookupPredefedObjCSuperType() called before performing builtin type comparisons.
      This fixes an error when compiling macOS headers. A test is added.
      
      Differential Revision: https://reviews.llvm.org/D87917
      fdab7563
    • Raul Tambre's avatar
      [Sema] Introduce BuiltinAttr, per-declaration builtin-ness · adf84530
      Raul Tambre authored
      Instead of relying on whether a certain identifier is a builtin, introduce BuiltinAttr to specify a declaration as having builtin semantics.
      
      This fixes incompatible redeclarations of builtins, as reverting the identifier as being builtin due to one incompatible redeclaration would have broken rest of the builtin calls.
      Mostly-compatible redeclarations of builtins also no longer have builtin semantics. They don't call the builtin nor inherit their attributes.
      A long-standing FIXME regarding builtins inside a namespace enclosed in extern "C" not being recognized is also addressed.
      
      Due to the more correct handling attributes for builtin functions are added in more places, resulting in more useful warnings.
      Tests are updated to reflect that.
      
      Intrinsics without an inline definition in intrin.h had `inline` and `static` removed as they had no effect and caused them to no longer be recognized as builtins otherwise.
      
      A pthread_create() related test is XFAIL-ed, as it relied on it being recognized as a builtin based on its name.
      The builtin declaration syntax is too restrictive and doesn't allow custom structs, function pointers, etc.
      It seems to be the only case and fixing this would require reworking the current builtin syntax, so this seems acceptable.
      
      Fixes PR45410.
      
      Reviewed By: rsmith, yutsumi
      
      Differential Revision: https://reviews.llvm.org/D77491
      adf84530
    • Erich Keane's avatar
      Stop ExtractTypeForDeductionGuide from recursing on TypeSourceInfo · 200eb1ab
      Erich Keane authored
      As reported in PR48177, the type-deduction extraction ends up going into
      an infinite loop when the type referred to has a recursive definition.
      This stops recursing and just substitutes the type-source-info the
      TypeLocBuilder identified when transforming the base.
      
      (cherry picked from commit 1c98f984)
      200eb1ab
  8. 14 Dec, 2020 6 commits
  9. 11 Dec, 2020 6 commits
    • Joseph Tremoulet's avatar
      [lldb] Report old modules from ModuleList::ReplaceEquivalent · abeec5d0
      Joseph Tremoulet authored
      This allows the Target to update its module list when loading a shared
      module replaces an equivalent one.
      
      A testcase is added which hits this codepath -- without the fix, the
      target reports libbreakpad.so twice in its module list.
      
      Reviewed By: jingham
      
      Differential Revision: https://reviews.llvm.org/D89157
      
      (cherry picked from commit d20aa7ca)
      abeec5d0
    • Joseph Tremoulet's avatar
      [lldb] GetSharedModule: Collect old modules in SmallVector · b618cf7a
      Joseph Tremoulet authored
      The various GetSharedModule methods have an optional out parameter for
      the old module when a file has changed or been replaced, which the
      Target uses to keep its module list current/correct.  We've been using
      a single ModuleSP to track "the" old module, and this change switches
      to using a SmallVector of ModuleSP, which has a couple benefits:
       - There are multiple codepaths which may discover an old module, and
         this centralizes the code for how to handle multiples in one place,
         in the Target code.  With the single ModuleSP, each place that may
         discover an old module is responsible for how it handles multiples,
         and the current code is inconsistent (some code paths drop the first
         old module, others drop the second).
       - The API will be more natural for identifying old modules in routines
         that work on sets, like ModuleList::ReplaceEquivalent (which I plan
         on updating to report old module(s) in a subsequent change to fix a
         bug).
      
      I'm not convinced we can ever actually run into the case that multiple
      old modules are found in the same GetOrCreateModule call, but I think
      this change makes sense regardless, in light of the above.
      
      When an old module is reported, Target::GetOrCreateModule calls
      m_images.ReplaceModule, which doesn't allow multiple "old" modules; the
      new code calls ReplaceModule for the first "old" module, and for any
      subsequent old modules it logs the event and calls m_images.Remove.
      
      Reviewed By: jingham
      
      Differential Revision: https://reviews.llvm.org/D89156
      
      (cherry picked from commit 61bfc703)
      b618cf7a
    • Joseph Tremoulet's avatar
      [lldb] Minidump: check for .text hash match with directory · 93fffe98
      Joseph Tremoulet authored
      When opening a minidump, we might discover that it reports a UUID for a
      module that doesn't match the build ID, but rather a hash of the .text
      section (according to either of two different hash functions, used by
      breakpad and Facebook respectively).  The current logic searches for a
      module by filename only to check the hash; this change updates it to
      first search by directory+filename.  This is important when the
      directory specified in the minidump must be interpreted relative to a
      user-provided sysoort, as the leaf directory won't be in the search path
      in that case.
      
      Also add a regression test; without this change, module validation fails
      because we have just the placeholder module which reports as its path
      the platform path in the minidump.
      
      Reviewed By: clayborg
      
      Differential Revision: https://reviews.llvm.org/D89155
      
      (cherry picked from commit d30797b4)
      93fffe98
    • Greg Clayton's avatar
      Add hashing of the .text section to ProcessMinidump. · 393eac16
      Greg Clayton authored
      Breakpad will always have a UUID for binaries when it creates minidump files. If an ELF files has a GNU build ID, it will use that. If it doesn't, it will create one by hashing up to the first 4096 bytes of the .text section. LLDB was not able to load these binaries even when we had the right binary because the UUID didn't match. LLDB will use the GNU build ID first as the main UUID for a binary and fallback onto a 8 byte CRC if a binary doesn't have one. With this fix, we will check for the Breakpad hash or the Facebook hash (a modified version of the breakpad hash that collides a bit less) and accept binaries when these hashes match.
      
      Differential Revision: https://reviews.llvm.org/D86261
      
      (cherry picked from commit 0e6c9a6e)
      393eac16
    • Joseph Tremoulet's avatar
      [lldb] Normalize paths in new test · 98fa2733
      Joseph Tremoulet authored
      The minidump-sysroot test I added in commit 20f84257 compares two paths
      using a string comparison.  This causes the Windows buildbot to fail
      because of mismatched forward slashes and backslashes.  Use
      os.path.normcase to normalize before comparing.
      
      (cherry picked from commit 4a55c98f)
      98fa2733
    • Joseph Tremoulet's avatar
      [lldb] Fix GetRemoteSharedModule fallback logic · 561e1ce1
      Joseph Tremoulet authored
      When the various methods of locating the module in GetRemoteSharedModule
      fail, make sure we pass the original module spec to the bail-out call to
      the provided resolver function.
      
      Also make sure we consistently use the resolved module spec from the
      various success paths.
      
      Thanks to what appears to have been an accidentally inverted condition
      (commit 85967fa3 applied the new condition to a path where GetModuleSpec
      returns false, but should have applied it when GetModuleSpec returns
      true), without this fix we only pass the original module spec in the
      fallback if the original spec has no uuid (or has a uuid that somehow
      matches the resolved module's uuid despite the call to GetModuleSpec
      failing).  This manifested as a bug when processing a minidump file with
      a user-provided sysroot, since in that case the resolver call was being
      applied to resolved_module_spec (despite resolution failing), which did
      not have the path of its file_spec set.
      
      Reviewed By: JDevlieghere
      
      Differential Revision: https://reviews.llvm.org/D88099
      
      (cherry picked from commit 20f84257)
      561e1ce1
  10. 10 Dec, 2020 1 commit
  11. 09 Dec, 2020 7 commits