[Lldb-commits] [PATCH] D62797: [Expression] Add PersistentExpressionState::GetCompilerTypeFromPersistentDecl

xiaobai updated this revision to Diff 203483. xiaobai added a comment. Renamed `clang_ast_type` to `compiler_type` to be more general. Allow for disambiguating by language with the flag `-x` or `--language`. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D62797/new/ https://reviews.llvm.o

[Lldb-commits] [PATCH] D62502: Implement xfer:libraries-svr4:read packet

aadsm added a comment. @labath that's a really good point. I've talked with @clayborg and @xiaobai about this and we decided it would be fine to do it manually as well so I added a `XMLEncodeAttributeValue` function to make it happen. I'm not 100% sure about its implementation.. Should I use a

[Lldb-commits] [PATCH] D62502: Implement xfer:libraries-svr4:read packet

aadsm updated this revision to Diff 203477. aadsm added a comment. No longer depend on libxml2 to quote the attribute value Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D62502/new/ https://reviews.llvm.org/D62502 Files: lldb/include/lldb/Host/XM

[Lldb-commits] [PATCH] D62501: Implement GetSharedLibraryInfoAddress

aadsm updated this revision to Diff 203476. aadsm added a comment. Herald added a subscriber: emaste. This creates a NativeProcessELF to deal with ELF specific things. The NativeProcessLinux now extends this one. Added a test case for the GetAuxValue and GetELFImageInfoAddress. I refactored Nati

[Lldb-commits] [PATCH] D62812: [llvm] [CodeView] Move Triple::ArchType → CPUType mapping from LLDB

mtrent added a reviewer: friss. mtrent added a comment. I am not familiar with lldb or with the DebugView library, so I am pulling in Fred Riss for this review. Thanks! CHANGES SINCE LAST ACTION https://reviews.llvm.org/D62812/new/ https://reviews.llvm.org/D62812 _

[Lldb-commits] [PATCH] D62980: [lldb] Replace "127.0.0.1" with "localhost" in GDBRemoteCommunication.cpp

jgorbe added a comment. Hm, I just realized I'm undoing https://reviews.llvm.org/D58883. I'll withdraw this patch and upload it again once I'm sure I'm taking that into account. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D62980/new/ https://reviews.llvm.org/D62980 ___

[Lldb-commits] [PATCH] D62980: [lldb] Replace "127.0.0.1" with "localhost" in GDBRemoteCommunication.cpp

jgorbe created this revision. jgorbe added reviewers: clayborg, labath. 127.0.0.1 doesn't work in machines configured with IPv6-only networking. https://reviews.llvm.org/D62980 Files: lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp Index: lldb/source/Plugins/Process/gdb-re

[Lldb-commits] [PATCH] D62948: lit/Register: Avoid stdio in register write tests

jgorbe added a comment. About %T not working for "process launch", what about something like `RUN: %lldb -b --one-line-before-file "process launch --stdout %T/x86-zmm-write.out" -s %s %t` and then FileCheck-ing? CHANGES SINCE LAST ACTION https://reviews.llvm.org/D62948/new/ https://reviews.

[Lldb-commits] [PATCH] D62934: [LanguageRuntime] Introdce LLVM-style casts

xiaobai updated this revision to Diff 203420. xiaobai added a comment. Implement labath's suggestion CHANGES SINCE LAST ACTION https://reviews.llvm.org/D62934/new/ https://reviews.llvm.org/D62934 Files: include/lldb/Target/CPPLanguageRuntime.h include/lldb/Target/LanguageRuntime.h incl

[Lldb-commits] [PATCH] D62501: Implement GetSharedLibraryInfoAddress

labath added a comment. Ok, makes sense, I'm happy that you've considered the dynamic loader sharing tradeoffs already. Let's go with the NativeProcessELF thingy then. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D62501/new/ https://reviews.llvm.o

[Lldb-commits] [PATCH] D62501: Implement GetSharedLibraryInfoAddress

aadsm added a comment. Interesting, I actually don't think there's much to gain from turning this into an utility. Creating a NativeProcessELF makes sense to me (I already did it and have all the tests up and running as well) and putting it into POSIX also makes sense to me based on what you sa

[Lldb-commits] [PATCH] D62948: lit/Register: Avoid stdio in register write tests

mgorny accepted this revision. mgorny added a comment. This revision is now accepted and ready to land. LGTM, thanks. I also hacked `-m32` for local testing. I generally agree this is a good thing to do but I don't really know how to reliably determine support for this. My main concern were C++

[Lldb-commits] [PATCH] D62948: lit/Register: Avoid stdio in register write tests

labath updated this revision to Diff 203378. labath added a comment. revert the 32-on-64-bit part CHANGES SINCE LAST ACTION https://reviews.llvm.org/D62948/new/ https://reviews.llvm.org/D62948 Files: lit/Register/x86-64-gp-write.test lit/Register/x86-64-write.test lit/Register/x86-64-x

[Lldb-commits] [PATCH] D62948: lit/Register: Avoid stdio in register write tests

labath added a comment. In D62948#1532549 , @mgorny wrote: > In D62948#1532531 , @labath wrote: > > > Update other tests too. I also forgot to mention that this enables the > > 32-bit > > tests to run on 64-bit pl

[Lldb-commits] [PATCH] D62948: lit/Register: Avoid stdio in register write tests

mgorny added a comment. In D62948#1532531 , @labath wrote: > Update other tests too. I also forgot to mention that this enables the 32-bit > tests to run on 64-bit platforms too by explicitly compiling for 32-bit > (-m32). I'm not sure if this is a goo

[Lldb-commits] [PATCH] D62948: lit/Register: Avoid stdio in register write tests

labath updated this revision to Diff 203370. labath added a comment. Update other tests too. I also forgot to mention that this enables the 32-bit tests to run on 64-bit platforms too by explicitly compiling for 32-bit (-m32). CHANGES SINCE LAST ACTION https://reviews.llvm.org/D62948/new/ htt

[Lldb-commits] [PATCH] D62931: [lldb-server] Add setting to force 'g' packet use

clayborg added a comment. In D62931#1531965 , @labath wrote: > Personally, I'm wondering whether we even need a setting for this. Running > the speed test command locally (i.e. the lowest latency we can possibly get), > I get results like: > > (lldb) p

[Lldb-commits] [PATCH] D62948: lit/Register: Avoid stdio in register write tests

mgorny added a comment. I'm sorry but could you also change other write tests (zmm?) to match. Comment at: lit/Register/x86-64-gp-write.test:6 # RUN: %lldb -b -s %s %t | FileCheck %s -process launch +# RUN: FileCheck %s --check-prefix=INF mgorny wrote: > > Any reason not to u

[Lldb-commits] [PATCH] D62948: lit/Register: Avoid stdio in register write tests

labath marked an inline comment as done. labath added inline comments. Comment at: lit/Register/x86-64-gp-write.test:6 # RUN: %lldb -b -s %s %t | FileCheck %s -process launch +# RUN: FileCheck %s --check-prefix=INF Any reason not to use `%T` directly in paths rather than changi

[Lldb-commits] [PATCH] D62948: lit/Register: Avoid stdio in register write tests

mgorny added inline comments. Comment at: lit/Register/x86-64-gp-write.test:6 # RUN: %lldb -b -s %s %t | FileCheck %s -process launch +# RUN: FileCheck %s --check-prefix=INF https://reviews.llvm.org/D62948/new/ https://reviews.llvm.org/D62948

[Lldb-commits] [PATCH] D62948: lit/Register: Avoid stdio in register write tests

labath created this revision. labath added reviewers: mgorny, jgorbe. The linux kernel doesn't guarantee that the data written to a pty will instantly be available for reading on the other side. So what sometimes happens here is that the inferior dumps all register values and exits, lldb registers

[Lldb-commits] [PATCH] D62943: DWARF: Simplify SymbolFileDWARF::GetDWARFCompileUnit

labath created this revision. labath added reviewers: clayborg, JDevlieghere. Herald added subscribers: jdoerfert, aprantl. The DWARFCompileUnit is set as the "user data" of the lldb compile unit directly in the constructor (see ParseCompileUnit). This means that instead of going through unit ind

[Lldb-commits] [PATCH] D62934: [LanguageRuntime] Introdce LLVM-style casts

labath added a comment. Implementing `classof` via an enum is the simplest and most common solution, but it is not the only thing possible. The central enum thingy is fine when all the subclasses are also defined centrally, but for a more distributed scenario like this one, it begins to smell,