Page MenuHomePhabricator
Feed Advanced Search

Yesterday

labath accepted D69320: [lldb] [Python] Do not attempt to flush() a read-only fd.
Tue, Oct 22, 10:53 PM

Mon, Oct 21

labath added a comment to D69148: Disable exit-on-SIGPIPE in lldb.

I'm not too worried about adding those tests here.

Mon, Oct 21, 4:42 PM · Restricted Project, Restricted Project
labath updated subscribers of D69286: I implemented the features listed in this document: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0616r0.pdf and built libc++ using ninja without any errors/warnings. I Also ran the test suite it using `lit` and passed all the unit tests..
Mon, Oct 21, 4:42 PM · Restricted Project
labath added a comment to D69148: Disable exit-on-SIGPIPE in lldb.
In D69148#1717361, @vsk wrote:

A problem I'm encountering with this is that the static initializer from Signals.inc don't appear to be re-run between death tests. This makes the death tests pretty brittle, imo, as swapping the order of the tests can break them. Do you think the extra coverage is worth it? (See https://reviews.llvm.org/D69283 for what this looks like.)

Mon, Oct 21, 4:33 PM · Restricted Project, Restricted Project
labath created D69285: minidump: Rename some architecture constants.
Mon, Oct 21, 3:59 PM · Restricted Project, Restricted Project
labath added a reviewer for D69230: RFC: specialized Optional<T> for T that can represent its own invalid state: dblaikie.

Lets loop in @dblaikie for start, and see how it goes from there. You can also check who modified/reviewed changes to this file lately..

Mon, Oct 21, 3:46 PM · Restricted Project, Restricted Project
labath added a comment to D69100: COFF: Create a separate "section" for the file header.

I'm OK with this. I'm just wondering whether it would be a good idea to make it clear that these header sections are "not considered to be a section in the strictest sense." Is the distinction going to be important to future code readers? Do we already have "sections" that aren't truly "sections"?

Perhaps just a comment where the header sections are created?

Mon, Oct 21, 2:04 PM
labath added a comment to D68961: Add support for DW_AT_export_symbols for anonymous structs .

When the I added the feature to the front end tests were added to verify that DW_AT_export_symbols is being generated for anonymous structs in D66605 and D66667 so if this regresses in the front-end we will catch it vis these tests. So as far I can tell we have tests at every point it can regress.

Mon, Oct 21, 1:54 PM
labath accepted D69214: remove multi-argument form of PythonObject::Reset().
Mon, Oct 21, 1:36 PM · Restricted Project
labath created D69273: ValueObject: Fix a crash related to children address type computation.
Mon, Oct 21, 10:55 AM
labath added inline comments to D69214: remove multi-argument form of PythonObject::Reset().
Mon, Oct 21, 6:34 AM · Restricted Project
labath accepted D69254: [lldb] drop .symtab removal in minidebuginfo tests.
Mon, Oct 21, 6:34 AM · Restricted Project

Sun, Oct 20

labath accepted D69226: [LLDB] [Windows] Initial support for ARM register contexts.
Sun, Oct 20, 3:02 PM · Restricted Project, Restricted Project
labath added a comment to D69214: remove multi-argument form of PythonObject::Reset().

I'm at the airport, so I haven't had a chance to look over the full set of changes you made, but here's my responses to your comments.

Sun, Oct 20, 12:21 AM · Restricted Project

Sat, Oct 19

labath added inline comments to D69133: eliminate nontrivial Reset(...) from TypedPythonObject.
Sat, Oct 19, 2:10 AM · Restricted Project
labath accepted D69133: eliminate nontrivial Reset(...) from TypedPythonObject.
Sat, Oct 19, 2:01 AM · Restricted Project
labath added a comment to D69214: remove multi-argument form of PythonObject::Reset().

No fudnamental issues with this patch (I'm ignoring the CStringArg topic here). I do think that it would be nice to have some more unit tests for the new APIs you're introducing (or elevating to API status). I'm mainly thinking of the PythonScript stuff (a test where we evaluate the script successfully) and the runString functions.

Sat, Oct 19, 1:51 AM · Restricted Project
labath added a comment to D69133: eliminate nontrivial Reset(...) from TypedPythonObject.

While I appreciate the desire to reduce "boilerplate", I also think there's a lot of value in consistency. None of the existing APIs in llvm do anything like this, and are perfectly happy to call toNullTerminatedStringRef manually. You've now introduced another string-like type, which people have to figure out how it works. If you really feel like you must avoid the extra line of code (because that's the only thing that this saves, really) then you could at least move the class into the implementation of the methods, so that at least the inferface is consistent with all other llvm functions taking an llvm::Twine. You could define an llvm::Twine constructor and a "const char *" conversion operator for this class, so that you can type Py_whatever(NullTerminated(twine)). This way we could also define a "char *" conversion operator on the class in the PY2 case, also avoiding the need for the py2_const_cast thingy.

Sat, Oct 19, 12:29 AM · Restricted Project
labath added a comment to D68130: [lldb] Don't emit artificial constructor declarations as global functions.

Well, I'm fine with x-failing it on Linux, even though I guess at some point someone (i.e., probably me) has to figure out why this stuff is broken in the expression parser.

Sat, Oct 19, 12:20 AM · Restricted Project
labath added a comment to D69148: Disable exit-on-SIGPIPE in lldb.
In D69148#1714785, @vsk wrote:

The death tests are flaky. I've noticed two issues:

  1. When run under lit, the DisableExitOnSIGPIPE doesn't actually exit when it receives SIGPIPE. Dtrace suggests that the unit test process inherits an "ignore" sigaction from its parent.
  2. When run in parallel, exiting causes the unit test to run atexit destructors for other unit tests lumped into the SupportTests binary. One of these is a condition_variable destructor and it hangs. Also, gtest warns: Death tests use fork(), which is unsafe particularly in a threaded context. For this test, Google Test detected 21 threads.

    So I plan to give up on testing "EnableExitOnSIGPIPE" and will write a non-death test to get some coverage.
Sat, Oct 19, 12:02 AM · Restricted Project, Restricted Project

Fri, Oct 18

labath accepted D69014: [LLDB] bugfix: command script add -f doesn't work for some callables.

I am happy with that.

Fri, Oct 18, 11:52 PM · Restricted Project
labath added a comment to D68968: [android/process info] Introduce display_name.

Cool. I'm glad we could figure this out.

Fri, Oct 18, 11:43 PM · Restricted Project
labath added a comment to D68130: [lldb] Don't emit artificial constructor declarations as global functions.

It doesn't seem to be failing here http://lab.llvm.org:8014/builders/lldb-x86_64-debian.

Fri, Oct 18, 12:40 PM · Restricted Project
labath committed rGea8b8fdf90d3: Add REQUIRES: x86 to more tests which need the x86 llvm target built (authored by labath).
Add REQUIRES: x86 to more tests which need the x86 llvm target built
Fri, Oct 18, 6:55 AM
labath committed rL375234: Add REQUIRES: x86 to more tests which need the x86 llvm target built.
Add REQUIRES: x86 to more tests which need the x86 llvm target built
Fri, Oct 18, 6:55 AM
labath added inline comments to D69102: COFF: Set section permissions.
Fri, Oct 18, 6:35 AM
labath added a comment to D69166: [LLDB] Do not take address of std::iscntrl in std::remove_if.

I already submitted the very same patch in r375221.

Fri, Oct 18, 6:25 AM · Restricted Project
labath updated the diff for D69100: COFF: Create a separate "section" for the file header.

Address review comments

Fri, Oct 18, 4:53 AM
labath added inline comments to D69100: COFF: Create a separate "section" for the file header.
Fri, Oct 18, 4:53 AM
labath committed rG0c3049177402: SystemInitializerCommon fix compilation on linux (authored by labath).
SystemInitializerCommon fix compilation on linux
Fri, Oct 18, 4:47 AM
labath committed rL375221: SystemInitializerCommon fix compilation on linux.
SystemInitializerCommon fix compilation on linux
Fri, Oct 18, 4:47 AM
labath added a comment to D69106: MemoryRegion: Print "don't know" permission values as such.

Looks good. Do we maybe want to use "unknown" instead of "don't know" when printing out the long for of a MemoryRegionInfo::OptionalBool? Or maybe "???"?

Fri, Oct 18, 4:42 AM
labath added inline comments to D69105: minidump: Create memory regions from the sections of loaded modules.
Fri, Oct 18, 4:30 AM
labath added a comment to D68961: Add support for DW_AT_export_symbols for anonymous structs .

We also have the lldb-cmake-matrix bot which runs the test suite using older versions of clang which is there for exactly this purpose to catch regressions due to features not supported by older compiler versions. Which would catch any regressions here.

Fri, Oct 18, 3:55 AM
labath added a comment to D69031: [LLDB] [test] Use %clang_cl instead of build.py in a few tests.

Check out lldb/test/Shell/helper/toolchain.py, you probably need to filter out some options for clang_cl specifically.

Yeah, I later found that. The issue is that it's passed to usr_clang in i llvm/utils/lit/lit/llvm/config.py, which sets all the provided additional flags on both %clang, %clangxx, %clang_cc1 and %clang_cl.

Maybe the additional_flags param needs to be split, into one common for all, one for gcc-style driver, one for clang_cl, and maybe also a separate one for cc1 (where not all driver level flags may fit either)?

Fri, Oct 18, 2:06 AM · Restricted Project
labath added a comment to D67793: new api class: SBFile.

BTW, I've had to add (or rather, extend) a fairly ugly hack in r373573 in order to get the new tests running on non-darwin platforms. The reason for that is that the FILE* out typemap needs to get the "mode" of the object in order to construct the python wrapper.

My hope is that we can be improved once you're finished your work here. For instance by reimplementing GetOutputFileHandle on top of GetOutputFile in swig, as the latter will (hopefully) be able to get the mode of a file correctly. Does that sound reasonable, or am I totally off-track here?

oops, sorry I missed this. Are you happy with how it all turned out?

Fri, Oct 18, 1:43 AM · Restricted Project, Restricted Project
labath accepted D69153: convert LLDBSwigPythonCallTypeScript to ArgInfo::max_positional_args.
Fri, Oct 18, 1:43 AM · Restricted Project
labath added a comment to D68968: [android/process info] Introduce display_name.

Thank you for doing the investigation, and the detailed summary. I'm going to respond inline.

Fri, Oct 18, 1:34 AM · Restricted Project
labath added inline comments to D69080: eliminate one form of PythonObject::Reset().
Fri, Oct 18, 12:34 AM · Restricted Project
labath added a comment to D69133: eliminate nontrivial Reset(...) from TypedPythonObject.

I think the conversion of different string types should be handled differently. Please see inline comment for details. Otherwise, this looks fine.

Fri, Oct 18, 12:23 AM · Restricted Project

Thu, Oct 17

labath added inline comments to D69080: eliminate one form of PythonObject::Reset().
Thu, Oct 17, 11:49 AM · Restricted Project
labath added inline comments to D69080: eliminate one form of PythonObject::Reset().
Thu, Oct 17, 11:30 AM · Restricted Project
labath added inline comments to D69080: eliminate one form of PythonObject::Reset().
Thu, Oct 17, 11:21 AM · Restricted Project
labath accepted D69119: Modernize the rest of the Find.* API (NFC).

yay

Thu, Oct 17, 11:12 AM · Restricted Project
labath added a parent revision for D69106: MemoryRegion: Print "don't know" permission values as such: D69105: minidump: Create memory regions from the sections of loaded modules.
Thu, Oct 17, 5:35 AM
labath created D69106: MemoryRegion: Print "don't know" permission values as such.
Thu, Oct 17, 5:35 AM
labath added a child revision for D69105: minidump: Create memory regions from the sections of loaded modules: D69106: MemoryRegion: Print "don't know" permission values as such.
Thu, Oct 17, 5:35 AM
labath added parent revisions for D69105: minidump: Create memory regions from the sections of loaded modules: D69102: COFF: Set section permissions, D69035: minidump: Refactor memory region computation code.
Thu, Oct 17, 5:26 AM
labath added a child revision for D69102: COFF: Set section permissions: D69105: minidump: Create memory regions from the sections of loaded modules.
Thu, Oct 17, 5:26 AM
labath added a child revision for D69035: minidump: Refactor memory region computation code: D69105: minidump: Create memory regions from the sections of loaded modules.
Thu, Oct 17, 5:26 AM
labath created D69105: minidump: Create memory regions from the sections of loaded modules.
Thu, Oct 17, 5:26 AM
labath requested review of D69035: minidump: Refactor memory region computation code.

With some additional COFF tweaks (D69100, D69102), the next patch doesn't turn out that bad (though I'm still happy to accept "unwinder should just check section permissions instead of us translating them to memory regions" as an answer).

Thu, Oct 17, 5:07 AM
labath added inline comments to D69102: COFF: Set section permissions.
Thu, Oct 17, 5:07 AM
labath created D69102: COFF: Set section permissions.
Thu, Oct 17, 5:07 AM
labath added a parent revision for D69102: COFF: Set section permissions: D69100: COFF: Create a separate "section" for the file header.
Thu, Oct 17, 5:07 AM
labath added a child revision for D69100: COFF: Create a separate "section" for the file header: D69102: COFF: Set section permissions.
Thu, Oct 17, 5:07 AM
labath created D69100: COFF: Create a separate "section" for the file header.
Thu, Oct 17, 4:57 AM
labath added a reverting change for D56537: ObjectFilePECOFF: Create a "container" section spanning the entire module image: D69100: COFF: Create a separate "section" for the file header.
Thu, Oct 17, 4:57 AM · Restricted Project, Restricted Project
labath accepted D68995: clean up the implementation of PythonCallable::GetNumArguments.

Looks like the old implementation also doesn't work for class or static methods, or for objects with __call__ method. I added a bunch of tests for script commands with various callable types in the followon patch.

Ok, I see... Would it be hard/impossible to fix that using the previous method, so that we have a unified implementation? Or would that result in a bunch of ifdefs too ? I'm sorry if that's obvious, but I don't know much about the C python api..

I did fix the previous method for python2, at least for the callable types I could think of to test.

There must be some way to get something resembling the old method to work for python3, because inspect does it. But it would be harder to get right, and a lot less likely to keep being correct in future versions of python. And I don't think it's possible to have a single implementation like that that works for both 2 and 3 without ifdefs.

Thu, Oct 17, 1:53 AM · Restricted Project
labath accepted D69080: eliminate one form of PythonObject::Reset().

I like where this is going.

Thu, Oct 17, 1:44 AM · Restricted Project
labath added a comment to D68968: [android/process info] Introduce display_name.

I don't think it would be good to make it hard to see the actual path (if you have it) as well as the bundle ID. If you are working on system components, you want to know that you are running some hand-built copy of a binary and not the pre-installed one. So we want to make it easy to see "which thing with this bundleID am I actually running". Other than that this seems fine to me.

Thu, Oct 17, 1:35 AM · Restricted Project
labath added a comment to D68995: clean up the implementation of PythonCallable::GetNumArguments.

Thanks for jumping onto this. Apart from the inline comments, I have one high level question: What are the cases that the old method is wrong for? Was it just builtin functions, or are there other cases too? Is it possible to fix it to work for builtings too? (okay, those were three questions)

What I am wondering is how important it is to maintain two methods for fetching the argument information. Builtin functions are not likely to be used as lldb callbacks, so if it's just those, it may be sufficient to just leave a TODO to use the new method once we are in a position to require python>=3.3.

Looks like the old implementation also doesn't work for class or static methods, or for objects with __call__ method. I added a bunch of tests for script commands with various callable types in the followon patch.

Thu, Oct 17, 12:58 AM · Restricted Project
labath added a comment to D69014: [LLDB] bugfix: command script add -f doesn't work for some callables.

I also think we shouldn't go out of our way (and I consider any kind of introspection as "going out of our way") to forbid calling with a "deprecated" signature for some callables even though there's technically no backward compatibility to worry about (because it was not possible to call those callables in the past). For "gentle discouragement" I'd rather just print a warning whenever we call any callable with a deprecated signature. That warning can explain the problem and how to fix it (and it's strength can be ramped up over time if we want to eventually remove these).

Thu, Oct 17, 12:21 AM · Restricted Project

Wed, Oct 16

labath added inline comments to D69031: [LLDB] [test] Use %clang_cl instead of build.py in a few tests.
Wed, Oct 16, 12:21 PM · Restricted Project
labath added a comment to D68961: Add support for DW_AT_export_symbols for anonymous structs .

Have many compilers supported DW_AT_export_symbols for a while now? If not, are there any serious issues introduced here that would change debugger behavior if this attribute is not emitted by a compiler? Or is this a new fix in clang that was recently introduced in order to fix an issue when debugging in lldb?

We don't except any regressions for code compiled with older compilers. We are fixing the case that unnamed classes are identified as anonymous. The anonymous classes cases should be caught in older revisions in ClangASTContext::AddFieldToRecordType which does a Rec->setAnonymousStructOrUnion(true) for those cases.

Wed, Oct 16, 11:15 AM
labath accepted D68293: [android/process list] support showing process arguments.
Wed, Oct 16, 11:15 AM · Restricted Project
labath planned changes to D69035: minidump: Refactor memory region computation code.

Actually, it looks like the "follow-up" patch will be more complicated than I had hoped for, and so I am starting to wonder whether we shouldn't just have the unwinder check for section permissions himself (which would be a one-liner). I'll need to investigate more, so you may want to hold off reviewing this.

Wed, Oct 16, 7:40 AM
labath created D69035: minidump: Refactor memory region computation code.
Wed, Oct 16, 6:51 AM
labath accepted D68134: [LLDB] Use the llvm microsoft demangler instead of the windows dbghelp api.
Wed, Oct 16, 6:27 AM · Restricted Project, Restricted Project
labath added a comment to D69031: [LLDB] [test] Use %clang_cl instead of build.py in a few tests.

It would be super-awesome if this worked, as this is exactly how the DWARF moral equivalents of these tests (e.g. test/Shell/SymbolFile/DWARF/debug-types.test) work. Let's see what Stella says about this.

Wed, Oct 16, 5:33 AM · Restricted Project
labath accepted D68963: delete SWIG typemaps for FILE*.
Wed, Oct 16, 4:49 AM · Restricted Project
labath added a comment to D68549: make ConstString allocate memory in non-tiny chunks.

Thinking more about this, maybe this is really not the right place and the change should be done in BumpPtrAllocator? To me it seems rather unreasonable that it would double the allocation size only after 128 allocations. Surely by the time it has already allocated 128*4096=0.5MiB memory it could have decided to raise the allocation size much sooner?

Wed, Oct 16, 4:39 AM · Restricted Project
labath added a comment to D68293: [android/process list] support showing process arguments.

Looks pretty good, just two quick comments.

Wed, Oct 16, 4:29 AM · Restricted Project
labath added a comment to D68980: [LLDB] [test] Allow specifying the full arch for msvc/clang-cl in build.py.

Having proper "target" support is one way to go, though I am disappointed to see it go this way, particularly as nobody really knows why invoking clang-cl directly should not work, and so the main motivation seems to be a fear of potentially breaking something, without understanding what that "something" is, or whether it even exists. The reason I am disappointed is because this script is a fairly big departure from the way most lit tests in llvm work, and it wasn't ever really fully embraced by the lldb community (as can be seen by the amount of %clangxx tests that could be using it, but aren't). And while I do think it has some benefits, I don't think it should be used as a replacement for all clang-cl invocations. If it turns out that there having a script wrapping clang-cl is a necessity (which I doubt), then I'd rather see a different python script (possibly reusing parts of this one) which just sets up the necessary environment, but otherwise forwards arguments to clang-cl verbatim. That would enable one to invoke clang-cl with any fancy argument he wants (and this could be hidden under %clang-cl), while leaving this script with the job of figuring out how to build a working host executable with a random compiler.

Wed, Oct 16, 4:20 AM · Restricted Project
labath added a comment to D68943: [llvm][yaml2obj] no more implicit ELF .symtab section.

Thank you guys for jumping onto this. This will be very useful in lldb.

Wed, Oct 16, 3:54 AM · Restricted Project, Restricted Project
labath added inline comments to D68541: Implement 'up' and 'down' shortcuts in lldb gui.
Wed, Oct 16, 3:54 AM · Restricted Project
labath accepted D69016: [lldb] move more things from python to cmake.

What are you trying to accomplish here?

Wed, Oct 16, 3:42 AM · Restricted Project
labath accepted D68872: SBCommandReturnObject: change LLDB_RECORD_METHOD(..., FILE *, ...) to use LLDB_RECORD_DUMMY.

Thanks for the suggestion. Applied. I have verified LD_LIBRARY_PATH=~/llvm/Release/lib ninja -C ~/llvm/Release check-lldb passes.

(I need LD_LIBRARY_PATH= to make check-lldb-lit pass on Linux. lit tests load ~/llvm/Release/lib/python2.7/dist-packages/lldb/_lldb.so, which specifies DT_RUNPATH=$ORIGIN/../lib. Unfortunately $ORIGIN is relative to the symlink itself, not the target file ~/llvm/Release/lib/liblldb.so.10.0.0svn)

Wed, Oct 16, 3:31 AM · Restricted Project
labath added a comment to D69014: [LLDB] bugfix: command script add -f doesn't work for some callables.

The code itself looks fine to me. Jim, is this ok from a scripting/compatibility/whatnot perspective?

Wed, Oct 16, 3:22 AM · Restricted Project
labath added a comment to D68995: clean up the implementation of PythonCallable::GetNumArguments.

Thanks for jumping onto this. Apart from the inline comments, I have one high level question: What are the cases that the old method is wrong for? Was it just builtin functions, or are there other cases too? Is it possible to fix it to work for builtings too? (okay, those were three questions)

Wed, Oct 16, 2:20 AM · Restricted Project
labath added a comment to D68549: make ConstString allocate memory in non-tiny chunks.

Yeah, allocating 256MB sounds a bit too much, particularly for lldb-server (ideally, I'd remove ConstString from lldb-server completely, but that's a different story). The reason for 256 string pools was to avoid/reduce locking contention when accessing the pool, but that does make the power-of-2 scaling in BumpPtrAllocator kick in too slowly.

Wed, Oct 16, 1:34 AM · Restricted Project
labath added a comment to D69008: Add arm64_32 support.

(looks good to me)

Wed, Oct 16, 1:22 AM · Restricted Project
labath added a reviewer for D68968: [android/process info] Introduce display_name: jingham.

Introducing a "bundle" identifier as a first class concept sounds reasonable to me, particularly if that concept can be applied to more than one platform. But since we're talking about iOS, it would be good to have the apple folks sign off on this idea too (+@jingham).

Wed, Oct 16, 1:12 AM · Restricted Project

Tue, Oct 15

labath added inline comments to D68671: Add the ability to pass extra args to a Python breakpoint command function.
Tue, Oct 15, 12:13 PM · Restricted Project
labath added inline comments to D68293: [android/process list] support showing process arguments.
Tue, Oct 15, 11:45 AM · Restricted Project
labath added a comment to D68980: [LLDB] [test] Allow specifying the full arch for msvc/clang-cl in build.py.

The two things that come to mind are the path to clang-cl (which is sometimes a clang build and sometimes installed on the system as part of a VS installation or an LLVM installation) as well as the path to the linker when it is needed. This is most often an issue in the case of a VS install - I don't remember all the details any more, but I believe that before Zach added the script, we were often picking up the wrong clang-cl and ending up not being able to compile the tests at all.

Tue, Oct 15, 11:35 AM · Restricted Project
labath added inline comments to D68671: Add the ability to pass extra args to a Python breakpoint command function.
Tue, Oct 15, 11:26 AM · Restricted Project
labath added a comment to D68620: DebugInfo: Use base address selection entries for debug_loc.

I haven't fully debugged this, but it looks like this change caused a failure on the Windows LLDB bot. There was already another failure, so you probably didn't get an email:

http://lab.llvm.org:8011/builders/lldb-x64-windows-ninja/builds/9772

Tue, Oct 15, 11:17 AM · Restricted Project
labath added inline comments to D68293: [android/process list] support showing process arguments.
Tue, Oct 15, 11:08 AM · Restricted Project
labath added a comment to D68980: [LLDB] [test] Allow specifying the full arch for msvc/clang-cl in build.py.

I suspect that using clang-cl directly will not work though - the script does a lot of the setup needed to run clang-cl correctly today (previously the environment for clang-cl was not setup correctly and the tests either didn't pass or passed for the wrong reasons, so using build.py has been a huge improvement).

Tue, Oct 15, 10:58 AM · Restricted Project
labath added inline comments to D68671: Add the ability to pass extra args to a Python breakpoint command function.
Tue, Oct 15, 10:48 AM · Restricted Project
labath added inline comments to D68671: Add the ability to pass extra args to a Python breakpoint command function.
Tue, Oct 15, 10:48 AM · Restricted Project
labath accepted D68737: SBFile::GetFile: convert SBFile back into python native files..
Tue, Oct 15, 7:39 AM · Restricted Project
labath added a comment to D68980: [LLDB] [test] Allow specifying the full arch for msvc/clang-cl in build.py.

Yeah, I raised this issue back when build.py was first introduced, but it did not really get resolved properly. (Back then, windows arm wasn't considered, so I guess the issue wasn't seen as pressing.)

Well, windows arm doesn't really affect this aspect at all. But if windows arm didn't exist, then clang-cl would probably error out more directly when run on arm linux, unless given an explicit architecture option.

Tue, Oct 15, 5:29 AM · Restricted Project
labath requested changes to D68980: [LLDB] [test] Allow specifying the full arch for msvc/clang-cl in build.py.

Yea, let's discuss this a bit further. It's possible this may turn out to be the best solution to the problem, but I'd like to explore the various aspects of the problem first...

Tue, Oct 15, 4:55 AM · Restricted Project
labath added a reviewer for D68980: [LLDB] [test] Allow specifying the full arch for msvc/clang-cl in build.py: stella.stamenova.

+stella, for the aspects of running msvc/clang in various environments..

Tue, Oct 15, 4:44 AM · Restricted Project
labath added a comment to D68293: [android/process list] support showing process arguments.

address comments

Btw, @labath, could you point me to a example of a full end to end test like the attach one you mention?
I haven't been able to find it :(

Tue, Oct 15, 4:21 AM · Restricted Project
labath added inline comments to D68671: Add the ability to pass extra args to a Python breakpoint command function.
Tue, Oct 15, 4:10 AM · Restricted Project
labath added a comment to D68963: delete SWIG typemaps for FILE*.

🍾

Tue, Oct 15, 1:00 AM · Restricted Project
labath accepted D68962: update ScriptInterpreterPython to use File, not FILE*.
Tue, Oct 15, 12:48 AM · Restricted Project