Page MenuHomePhabricator

xiaobai (Alex Langford)
uwu

Projects

User does not belong to any projects.

User Details

User Since
Mar 21 2017, 11:50 AM (112 w, 5 d)

Recent Activity

Fri, May 17

xiaobai added a comment to D61833: Fix IPv6 support on lldb-server platform.

This broke windows buildbots. I tried to fix with svn r361083 but there were other things that got broken. @aadsm: We should revisit this patch next week and see what we need to fix up before it goes in.

Fri, May 17, 7:04 PM · Restricted Project
xiaobai committed rG38cc896f0026: Revert "Fix IPv6 support on lldb-server platform" (authored by xiaobai).
Revert "Fix IPv6 support on lldb-server platform"
Fri, May 17, 6:09 PM
xiaobai committed rLLDB361086: Revert "Fix IPv6 support on lldb-server platform".
Revert "Fix IPv6 support on lldb-server platform"
Fri, May 17, 6:09 PM
xiaobai committed rL361086: Revert "Fix IPv6 support on lldb-server platform".
Revert "Fix IPv6 support on lldb-server platform"
Fri, May 17, 6:09 PM
xiaobai committed rGf9399de525e5: Unbreak windows build bot (authored by xiaobai).
Unbreak windows build bot
Fri, May 17, 5:13 PM
xiaobai committed rLLDB361083: Unbreak windows build bot.
Unbreak windows build bot
Fri, May 17, 5:07 PM
xiaobai committed rL361083: Unbreak windows build bot.
Unbreak windows build bot
Fri, May 17, 5:07 PM
xiaobai committed rGd84d02e1973a: Fix IPv6 support on lldb-server platform (authored by xiaobai).
Fix IPv6 support on lldb-server platform
Fri, May 17, 3:29 PM
xiaobai committed rL361079: Fix IPv6 support on lldb-server platform.
Fix IPv6 support on lldb-server platform
Fri, May 17, 3:29 PM
xiaobai committed rLLDB361079: Fix IPv6 support on lldb-server platform.
Fix IPv6 support on lldb-server platform
Fri, May 17, 3:29 PM
xiaobai closed D61833: Fix IPv6 support on lldb-server platform.
Fri, May 17, 3:29 PM · Restricted Project
xiaobai added a comment to D61833: Fix IPv6 support on lldb-server platform.

Landed -- r361079

Fri, May 17, 3:29 PM · Restricted Project
xiaobai added a comment to D61476: [WIP] Add command interpreter to lldb-vscode.

I like the idea of this commit, it seems like we can have lldb-vscode be more useful than just a DAP frontend to lldb.

Fri, May 17, 11:10 AM
xiaobai added a comment to D61952: [CMake] Stabilize install process for LLDB.framework.

@xiaobai Out of interest: have you faced overwrite issues when running install and would this patch help?

Fri, May 17, 10:43 AM · Restricted Project

Thu, May 16

xiaobai committed rGd2284128a9c8: [Target] Stop linking against lldbPluginObjCLanguage (authored by xiaobai).
[Target] Stop linking against lldbPluginObjCLanguage
Thu, May 16, 3:01 PM
xiaobai committed rL360945: [Target] Stop linking against lldbPluginObjCLanguage.
[Target] Stop linking against lldbPluginObjCLanguage
Thu, May 16, 3:00 PM
xiaobai committed rLLDB360945: [Target] Stop linking against lldbPluginObjCLanguage.
[Target] Stop linking against lldbPluginObjCLanguage
Thu, May 16, 3:00 PM
xiaobai added inline comments to D61956: [CMake] Add first CMake cache files.
Thu, May 16, 11:35 AM · Restricted Project, Restricted Project
xiaobai added a comment to D61956: [CMake] Add first CMake cache files.

I noticed you have lots of comments that say "Release has different values for these variables". I think that you could instead guard the Release configuration behind a check. For example:

if (CMAKE_BUILD_TYPE MATCHES Release)
  # Do the release configuration stuff here
else()
  # Do the development configuration stuff here
endif()
Thu, May 16, 11:34 AM · Restricted Project, Restricted Project
xiaobai added a comment to D61994: [CommandInterpreter] Refactor SourceInitFile.

Seems like an overall improvement to the structure of this code. At the high level, the structure feels easier to understand.

Thu, May 16, 10:55 AM · Restricted Project, Restricted Project

Wed, May 15

xiaobai added a comment to D61921: [Target] Generalize language-specific behavior in ThreadPlanStepThrough.

If this iteration is going to be used a lot, I'd recommend taking a bit of time to implement an iterator abstraction over the language runtimes. It takes a bit longer to set up, but I hope we can all agree that for (runtime: process->GetLanguageRuntimes()) runtime->foo(); is more readable than process->ForEachLanguageRuntime([] (runtime) { runtime->foo(); }). This is particularly true if you need some sort of a control flow construct (continue, break, return) in the loop "body".

+1

Wed, May 15, 10:55 AM

Tue, May 14

xiaobai committed rGbd3adfe5e3bc: [Target] Generalize some behavior in Thread (authored by xiaobai).
[Target] Generalize some behavior in Thread
Tue, May 14, 6:46 PM
xiaobai committed rL360741: [Target] Generalize some behavior in Thread.
[Target] Generalize some behavior in Thread
Tue, May 14, 6:46 PM
xiaobai committed rLLDB360741: [Target] Generalize some behavior in Thread.
[Target] Generalize some behavior in Thread
Tue, May 14, 6:46 PM
xiaobai closed D61776: [Target] Generalize some behavior in Thread.
Tue, May 14, 6:46 PM · Restricted Project
xiaobai added a comment to D61921: [Target] Generalize language-specific behavior in ThreadPlanStepThrough.

Getting it from the Process's m_language_runtimes is probably fine. On reflection, I can't think of a reason why you would want to iterate over all the available LanguageRuntimes, including the ones that hadn't been recognized in this Process yet.

It's fine to do that in a separate patch. If you do that it would be good to back port it to the other iterations over the LanguageRuntimes.

Tue, May 14, 6:43 PM
xiaobai added a comment to D61921: [Target] Generalize language-specific behavior in ThreadPlanStepThrough.

There is a TypeSystemEnumerateSupportedLanguages that we use so that we don't have to enumerate over all the language in the languages enums. After all the plugin manager knows which languages we have type systems for. If you're going to be doing a lot of this generalization, can you add a similar enumeration for the LanguageRuntimes? There are 40 or so languages in the language enum but we only have a couple of LanguageRuntimes...

Tue, May 14, 5:57 PM
xiaobai added inline comments to D61921: [Target] Generalize language-specific behavior in ThreadPlanStepThrough.
Tue, May 14, 3:29 PM
xiaobai created D61921: [Target] Generalize language-specific behavior in ThreadPlanStepThrough.
Tue, May 14, 3:20 PM

Mon, May 13

xiaobai updated the diff for D61776: [Target] Generalize some behavior in Thread.
  • Fix minor bug in ItaniumABILanguageRuntime
  • Modify test to accomodate new behavior
Mon, May 13, 9:02 PM · Restricted Project
xiaobai added a comment to D61776: [Target] Generalize some behavior in Thread.

Unfortunately I can't land this patch as-is. With this patch applied, TestObjCExceptions fails. It looks like c++ exceptions are supported at the bare minimum as a part of the objc exception handling logic.

Mon, May 13, 6:40 PM · Restricted Project

Fri, May 10

xiaobai committed rG58a638b79f45: [Breakpoint] Make breakpoint language agnostic (authored by xiaobai).
[Breakpoint] Make breakpoint language agnostic
Fri, May 10, 8:31 PM
xiaobai committed rLLDB360509: [Breakpoint] Make breakpoint language agnostic.
[Breakpoint] Make breakpoint language agnostic
Fri, May 10, 8:31 PM
xiaobai committed rL360509: [Breakpoint] Make breakpoint language agnostic.
[Breakpoint] Make breakpoint language agnostic
Fri, May 10, 8:31 PM
xiaobai closed D61746: [Breakpoint] Make breakpoint language agnostic.
Fri, May 10, 8:30 PM · Restricted Project
xiaobai updated the diff for D61746: [Breakpoint] Make breakpoint language agnostic.
  • Fix minor bug
  • Return vector by value instead of passing in one by parameter.
Fri, May 10, 5:46 PM · Restricted Project
xiaobai updated the diff for D61776: [Target] Generalize some behavior in Thread.

Add comments to give better context

Fri, May 10, 12:14 PM · Restricted Project
xiaobai added a comment to D61776: [Target] Generalize some behavior in Thread.

If you really are going to support many languages you need to figure out how to tell folks what really happened with more specificity.

Fri, May 10, 11:56 AM · Restricted Project

Thu, May 9

xiaobai created D61776: [Target] Generalize some behavior in Thread.
Thu, May 9, 7:58 PM · Restricted Project
xiaobai updated the diff for D61746: [Breakpoint] Make breakpoint language agnostic.

Rework function
GetVariantMethodNames -> GetMethodNameVariants

Thu, May 9, 2:32 PM · Restricted Project
xiaobai added a comment to D61746: [Breakpoint] Make breakpoint language agnostic.

Thanks for the feedback!

Thu, May 9, 2:23 PM · Restricted Project
xiaobai created D61746: [Breakpoint] Make breakpoint language agnostic.
Thu, May 9, 11:25 AM · Restricted Project

Tue, May 7

xiaobai committed rG8b6071f561a7: [Expression] Remove unused dependency (authored by xiaobai).
[Expression] Remove unused dependency
Tue, May 7, 4:10 PM
xiaobai committed rLLDB360208: [Expression] Remove unused dependency.
[Expression] Remove unused dependency
Tue, May 7, 4:10 PM
xiaobai committed rL360208: [Expression] Remove unused dependency.
[Expression] Remove unused dependency
Tue, May 7, 4:10 PM
xiaobai added a comment to D61659: Fix bug in ArchSpec::MergeFrom.

Ah, this was my bad. Thanks for taking care of this.

Tue, May 7, 3:12 PM · Restricted Project
xiaobai committed rGb2fa002c83a4: [Core] Remove unused dependencies (authored by xiaobai).
[Core] Remove unused dependencies
Tue, May 7, 2:35 PM
xiaobai committed rLLDB360193: [Core] Remove unused dependencies.
[Core] Remove unused dependencies
Tue, May 7, 2:34 PM
xiaobai committed rL360193: [Core] Remove unused dependencies.
[Core] Remove unused dependencies
Tue, May 7, 2:34 PM
xiaobai committed rGfb381607f00e: [Host] Clean up dependencies of HostMacOSXObjCXX (authored by xiaobai).
[Host] Clean up dependencies of HostMacOSXObjCXX
Tue, May 7, 11:07 AM
xiaobai committed rL360178: [Host] Clean up dependencies of HostMacOSXObjCXX.
[Host] Clean up dependencies of HostMacOSXObjCXX
Tue, May 7, 11:06 AM
xiaobai committed rLLDB360178: [Host] Clean up dependencies of HostMacOSXObjCXX.
[Host] Clean up dependencies of HostMacOSXObjCXX
Tue, May 7, 11:06 AM

Mon, May 6

xiaobai committed rG6bc219e6bf61: [Breakpoint] Remove unused dependency (authored by xiaobai).
[Breakpoint] Remove unused dependency
Mon, May 6, 6:02 PM
xiaobai committed rLLDB360105: [Breakpoint] Remove unused dependency.
[Breakpoint] Remove unused dependency
Mon, May 6, 6:02 PM
xiaobai committed rL360105: [Breakpoint] Remove unused dependency.
[Breakpoint] Remove unused dependency
Mon, May 6, 6:02 PM

Thu, May 2

xiaobai accepted D61425: Install import libraries.

Looks like the right thing to do to me. As beanz said, selectively choosing is unneeded work.

Thu, May 2, 11:59 AM · Restricted Project

Wed, May 1

xiaobai committed rGd6b469dd058f: [CMake] Remove EmulateInstructionMIPS dependency on Interpreter (authored by xiaobai).
[CMake] Remove EmulateInstructionMIPS dependency on Interpreter
Wed, May 1, 6:12 PM
xiaobai committed rLLDB359748: [CMake] Remove EmulateInstructionMIPS dependency on Interpreter.
[CMake] Remove EmulateInstructionMIPS dependency on Interpreter
Wed, May 1, 6:08 PM
xiaobai committed rL359748: [CMake] Remove EmulateInstructionMIPS dependency on Interpreter.
[CMake] Remove EmulateInstructionMIPS dependency on Interpreter
Wed, May 1, 6:08 PM
xiaobai accepted D61362: lldb-server: remove link against lldbInterpreter.

Seems like the right thing to do.

Wed, May 1, 2:53 PM · Restricted Project
xiaobai committed rG4e7104bd637e: [lldb-server] Remove lldb-server's dependency on Core (authored by xiaobai).
[lldb-server] Remove lldb-server's dependency on Core
Wed, May 1, 2:44 PM
xiaobai committed rLLDB359730: [lldb-server] Remove lldb-server's dependency on Core.
[lldb-server] Remove lldb-server's dependency on Core
Wed, May 1, 2:43 PM
xiaobai committed rL359730: [lldb-server] Remove lldb-server's dependency on Core.
[lldb-server] Remove lldb-server's dependency on Core
Wed, May 1, 2:43 PM
xiaobai added inline comments to D61360: Initialization: remove ObjectContainer from Common.
Wed, May 1, 1:28 PM · Restricted Project

Tue, Apr 30

xiaobai committed rG10e4b860de90: [CMake] Correct lldbPluginProcessPOSIX dependencies (authored by xiaobai).
[CMake] Correct lldbPluginProcessPOSIX dependencies
Tue, Apr 30, 8:21 PM
xiaobai committed rLLDB359645: [CMake] Correct lldbPluginProcessPOSIX dependencies.
[CMake] Correct lldbPluginProcessPOSIX dependencies
Tue, Apr 30, 8:21 PM
xiaobai committed rL359645: [CMake] Correct lldbPluginProcessPOSIX dependencies.
[CMake] Correct lldbPluginProcessPOSIX dependencies
Tue, Apr 30, 8:21 PM
xiaobai added inline comments to D61360: Initialization: remove ObjectContainer from Common.
Tue, Apr 30, 8:21 PM · Restricted Project

Mon, Apr 29

xiaobai committed rGbabcbaf97172: [CMake] Fix subtle CMake bug (authored by xiaobai).
[CMake] Fix subtle CMake bug
Mon, Apr 29, 12:46 PM
xiaobai committed rL359490: [CMake] Fix subtle CMake bug.
[CMake] Fix subtle CMake bug
Mon, Apr 29, 12:46 PM
xiaobai committed rLLDB359490: [CMake] Fix subtle CMake bug.
[CMake] Fix subtle CMake bug
Mon, Apr 29, 12:46 PM

Tue, Apr 23

xiaobai committed rGbfd248d2a67f: [CMake] Use add_dependencies in add_llvm_install_targets (authored by xiaobai).
[CMake] Use add_dependencies in add_llvm_install_targets
Tue, Apr 23, 2:58 PM
xiaobai committed rL359042: [CMake] Use add_dependencies in add_llvm_install_targets.
[CMake] Use add_dependencies in add_llvm_install_targets
Tue, Apr 23, 2:57 PM
xiaobai closed D60879: [CMake] Use add_dependencies in add_llvm_install_targets.
Tue, Apr 23, 2:57 PM · Restricted Project

Apr 18 2019

xiaobai added a reviewer for D60879: [CMake] Use add_dependencies in add_llvm_install_targets: compnerd.
Apr 18 2019, 5:22 PM · Restricted Project
xiaobai updated the summary of D60879: [CMake] Use add_dependencies in add_llvm_install_targets.
Apr 18 2019, 10:51 AM · Restricted Project
xiaobai created D60879: [CMake] Use add_dependencies in add_llvm_install_targets.
Apr 18 2019, 10:47 AM · Restricted Project

Apr 16 2019

xiaobai committed rG7603bd52e399: [Process] Fix linux arm64 single step compilation failure (authored by xiaobai).
[Process] Fix linux arm64 single step compilation failure
Apr 16 2019, 2:21 PM
xiaobai committed rLLDB358530: [Process] Fix linux arm64 single step compilation failure.
[Process] Fix linux arm64 single step compilation failure
Apr 16 2019, 2:21 PM
xiaobai committed rL358530: [Process] Fix linux arm64 single step compilation failure.
[Process] Fix linux arm64 single step compilation failure
Apr 16 2019, 2:21 PM

Apr 8 2019

xiaobai added a comment to D60157: [NativePDB] Add a check for nullptr for a TagTypeNode.

If you fail the parse the TTN of a symbol, demangler.Error should be true, no? That seems like a demangler error to me. :P

Apr 8 2019, 4:51 PM

Apr 5 2019

xiaobai committed rG7e7f79ccb19d: [CMake] Don't explicitly use LLVM_LIBRARY_DIR in standalone builds (authored by xiaobai).
[CMake] Don't explicitly use LLVM_LIBRARY_DIR in standalone builds
Apr 5 2019, 2:01 PM
xiaobai committed rL357817: [CMake] Don't explicitly use LLVM_LIBRARY_DIR in standalone builds.
[CMake] Don't explicitly use LLVM_LIBRARY_DIR in standalone builds
Apr 5 2019, 2:01 PM
xiaobai committed rLLDB357817: [CMake] Don't explicitly use LLVM_LIBRARY_DIR in standalone builds.
[CMake] Don't explicitly use LLVM_LIBRARY_DIR in standalone builds
Apr 5 2019, 2:01 PM
xiaobai closed D60180: [CMake] Don't explicitly use LLVM_LIBRARY_DIR in standalone builds.
Apr 5 2019, 2:01 PM · Restricted Project
xiaobai added a comment to D60180: [CMake] Don't explicitly use LLVM_LIBRARY_DIR in standalone builds.

No, everything is being built for android. Cross-compiling lldb-server involves cross-compiling llvm libraries, clang libraries, and if you've got swift in the picture, swift host libraries. LLVM and clang libraries are built against the libc++ from the android NDK, but in standalone builds, LLDB will try to link against the freshly built libc++ from LLVM. You get loads of undefined references to symbols from the NDK's libc++.

For the link_directories line: if you cross-compile the entire tree and this tree contains libc++, wouldn't it be natural that LLDB will try to link against the freshly built libc++?
If this is not your intention, then maybe we need a LLDB_EXTERNAL_LIBCXX option instead?

Apr 5 2019, 11:49 AM · Restricted Project

Apr 4 2019

xiaobai added a comment to D60180: [CMake] Don't explicitly use LLVM_LIBRARY_DIR in standalone builds.

LLVM_LIBRARY_DIR is being set correctly. It appears to be getting it from the LLVMConfig we get from find_package(LLVM).

Yes LLVMConfig sets the variable, but it's not going to be in the cache:

llvm-macosx-x86_64/lib/cmake/llvm/LLVMConfig.cmake
178:set(LLVM_LIBRARY_DIR "/path/to/llvm-macosx-x86_64/./lib")

Does cmake -L ... still dump it? Do in-tree builds have a cache entry for it? Are other subprojects relying on it? (unlikely for LLDB)

Apr 4 2019, 3:25 PM · Restricted Project

Apr 3 2019

xiaobai added a comment to D60180: [CMake] Don't explicitly use LLVM_LIBRARY_DIR in standalone builds.

So I ran the lldb test suite from a standalone build tree, and this patch didn't change anything. I added some logging to the CMake and LLVM_LIBRARY_DIR is being set correctly. It appears to be getting it from the LLVMConfig we get from find_package(LLVM). I think we could also get rid of LLVM_BINARY_DIR if that's the case, since it appears we only set it for lit.

Apr 3 2019, 2:07 PM · Restricted Project
xiaobai added a comment to D60180: [CMake] Don't explicitly use LLVM_LIBRARY_DIR in standalone builds.

Major concern from my side is that clang does something like this too:

clang/CMakeLists.txt
86:  set(LLVM_LIBRARY_DIR ${LIBRARY_DIR} CACHE PATH "Path to llvm/lib")
125:  link_directories("${LLVM_LIBRARY_DIR}")

It looks like AddLLVM.cmake uses it in function configure_lit_site_cfg:

# They below might not be the build tree but provided binary tree.
set(LLVM_SOURCE_DIR ${LLVM_MAIN_SRC_DIR})
set(LLVM_BINARY_DIR ${LLVM_BINARY_DIR})
string(REPLACE "${CMAKE_CFG_INTDIR}" "${LLVM_BUILD_MODE}" LLVM_TOOLS_DIR "${LLVM_TOOLS_BINARY_DIR}")
string(REPLACE ${CMAKE_CFG_INTDIR} ${LLVM_BUILD_MODE} LLVM_LIBS_DIR  "${LLVM_LIBRARY_DIR}")

So we should always have some value for LLVM_LIBRARY_DIR. Not sure about the link_directories line.
Did you build and run test suite with this change? How does this string Replace work then?

Apr 3 2019, 10:49 AM · Restricted Project

Apr 2 2019

xiaobai added a reviewer for D60180: [CMake] Don't explicitly use LLVM_LIBRARY_DIR in standalone builds: mgorny.
Apr 2 2019, 11:21 PM · Restricted Project
xiaobai created D60180: [CMake] Don't explicitly use LLVM_LIBRARY_DIR in standalone builds.
Apr 2 2019, 11:21 PM · Restricted Project

Mar 28 2019

xiaobai added a comment to D59911: Don't abort() in lldb_assert and document why..

Thank you for taking the time to write this up! I wish I could have read this when I started working on LLDB. :)

Mar 28 2019, 3:20 PM · Restricted Project, Restricted Project

Mar 26 2019

xiaobai committed rG982726ea010f: [ExpressionParser] Add swift-lldb case for finding clang resource dir (authored by xiaobai).
[ExpressionParser] Add swift-lldb case for finding clang resource dir
Mar 26 2019, 2:02 PM
xiaobai committed rL357030: [ExpressionParser] Add swift-lldb case for finding clang resource dir.
[ExpressionParser] Add swift-lldb case for finding clang resource dir
Mar 26 2019, 2:02 PM
xiaobai committed rLLDB357030: [ExpressionParser] Add swift-lldb case for finding clang resource dir.
[ExpressionParser] Add swift-lldb case for finding clang resource dir
Mar 26 2019, 2:02 PM
xiaobai closed D59708: [ExpressionParser] Add swift-lldb case for finding clang resource dir.
Mar 26 2019, 2:02 PM · Restricted Project
xiaobai added inline comments to D59708: [ExpressionParser] Add swift-lldb case for finding clang resource dir.
Mar 26 2019, 11:45 AM · Restricted Project

Mar 25 2019

xiaobai updated the diff for D59708: [ExpressionParser] Add swift-lldb case for finding clang resource dir.

Added comment about verify

Mar 25 2019, 2:24 PM · Restricted Project
xiaobai added a comment to D59708: [ExpressionParser] Add swift-lldb case for finding clang resource dir.

I changed the default behavior here setting file_spec to some known default unverified value to not setting it at all. It previously relied on there being a relative path to the clang resource dir, of which there are now two to pick from. Additionally, we pass in the directory containing liblldb to ComputeClangResourceDirectory now. The default behavior of HostInfo::ComputePathRelativeToLibrary was just computing it again and munging paths without verifying it. I think that if we fail to find the clang resource directory, the logs here should be sufficient to get started debugging.

Mar 25 2019, 1:02 PM · Restricted Project
xiaobai updated the diff for D59708: [ExpressionParser] Add swift-lldb case for finding clang resource dir.
  • Respect LIBDIR for swift-lldb case
  • Loop over a list of known directory suffixes
  • Change default behavior to not set file_spec and return false upon failure.
Mar 25 2019, 12:53 PM · Restricted Project