[Lldb-commits] [PATCH] D86388: Fix use-after-free in ThreadPlan, and add test.

comex added a comment. In D86388#2234418 , @jingham wrote: > I'm confused as to how this patch actually fixes the problem. When the > thread gets removed from the thread list, it should get Destroy called on it > - which should set m_destroy_called, cau

[Lldb-commits] [PATCH] D79219: [CMake] Simplify CMake handling for zlib

mati865 added a comment. @phosek > Looks like that's an issue introduced by D86134 > or D86245 . Indeed, I apologize for bothering you. Should I move the discussion to one of patches created by @haampie? Continuing the discus

[Lldb-commits] [PATCH] D85820: Use find_library for ncurses

haampie added a comment. @gkistanova It's true that this change has lead to more issues I could ever imagine, but I think the link you provided is the last remaining problem. Pinging @phosek for a similar issue w.r.t. zlib: since https://reviews.llvm.org/D79219 zlib gets disabled on static buil

[Lldb-commits] [PATCH] D86521: Revert "Use find_library for ncurses"

haampie created this revision. haampie added reviewers: JDevlieghere, phosek, gkistanova. Herald added subscribers: llvm-commits, lldb-commits, Sanitizers, hiraditya, mgorny. Herald added projects: Sanitizers, LLDB, LLVM. haampie requested review of this revision. The introduction of find_library

[Lldb-commits] [PATCH] D85820: Use find_library for ncurses

gkistanova reopened this revision. gkistanova added a comment. This revision is now accepted and ready to land. @haampie Are you working on fixing the http://lab.llvm.org:8011/builders/lld-perf-testsuite bot? This patch has broken it. FAILED: bin/llvm-tblgen : && /usr/bin/c++ -fvisibility

[Lldb-commits] [PATCH] D79219: [CMake] Simplify CMake handling for zlib

phosek added a comment. In D79219#2231927 , @mati865 wrote: > @phosek in MSYS2 (targeting x86_64-w64-windows-gnu) Zlib works properly for > LLVM 10 but with master I'm now seeing: > > -- Constructing LLVMBuild project information > -- DEBUG zlib_libra

[Lldb-commits] [PATCH] D86417: [lldb] do not propagate eTrapHandlerFrame repeatedly

JosephTremoulet added a comment. > And its parent 'raise' is set so as well because of > 'GetNextFrame()->m_frame_type == eTrapHandlerFrame '. Sorry, can you clarify what code path you're referring to here? I see two occurrences of `GetNextFrame()->m_frame_type == eTrapHandlerFrame` in the cod

[Lldb-commits] [PATCH] D86417: [lldb] do not propagate eTrapHandlerFrame repeatedly

llunak added a comment. In D86417#2236337 , @JosephTremoulet wrote: >> And its parent 'raise' is set so as well because of >> 'GetNextFrame()->m_frame_type == eTrapHandlerFrame '. > > Sorry, can you clarify what code path you're referring to here? I see

[Lldb-commits] [PATCH] D86493: [lldb][NFC] Remove unused/misnamed SetObjectModificationTime

aprantl accepted this revision. aprantl added a comment. This revision is now accepted and ready to land. Sometimes these odd leaf APIs are used by custom downstream variants of LLDB, but without any comment pointing into that direction and no unit test, I think this makes sense to remove. Also,

[Lldb-commits] [PATCH] D86493: [lldb][NFC] Remove unused/misnamed SetObjectModificationTime

JDevlieghere accepted this revision. JDevlieghere added a comment. Nice Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D86493/new/ https://reviews.llvm.org/D86493 ___ lldb-commits mailing list lldb-commits

[Lldb-commits] [PATCH] D86493: [lldb][NFC] Remove unused/misnamed SetObjectModificationTime

kastiglione added a comment. In D86493#2236454 , @aprantl wrote: > Sometimes these odd leaf APIs are used by custom downstream variants of LLDB I wondered about other consumers, how often is it the case that mainline lldb has code used only downstream?

[Lldb-commits] [PATCH] D86493: [lldb][NFC] Remove unused/misnamed SetObjectModificationTime

aprantl added a comment. The largest downstream LLDB fork that I know about is swift-lldb, which is also open source and thus easy to check. There also exists a Rust version, and many custom forks for various specialized hardware. Putting patches up for review here gives the maintainers a chanc

[Lldb-commits] [PATCH] D86497: [lldb] Add reproducer verifier

JDevlieghere updated this revision to Diff 287710. JDevlieghere added a comment. Herald added a subscriber: ormris. - Add tests - Extract common code from `CommandObjectReproducerDump` and `CommandObjectReproducerVerify` into `GetLoaderFromPathOrCurrent` - Address code review feedback CHANGES S

[Lldb-commits] [PATCH] D86493: [lldb][NFC] Remove unused/misnamed SetObjectModificationTime

aprantl added a comment. I should also mention that we are actively looking into ways to upstream the swift-lldb code into llvm.org. Now that both branches are licensed under Apache the only challenge left is to make the Swift support a real language *plugin* that can be conditionally compiled.

[Lldb-commits] [PATCH] D86497: [lldb] Add reproducer verifier

JDevlieghere updated this revision to Diff 287713. JDevlieghere added a comment. - Make CHECK-line more specific CHANGES SINCE LAST ACTION https://reviews.llvm.org/D86497/new/ https://reviews.llvm.org/D86497 Files: lldb/include/lldb/Utility/ReproducerProvider.h lldb/source/Commands/Comma

[Lldb-commits] [PATCH] D86389: [lldb] Add a SymbolFileProvider to record and replay calls to dsymForUUID

teemperor added a comment. Pretty sure this broke some tests http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/23476/ Note: Google Test filter = SymbolsTest.LocateExecutableSymbolFileForUnknownExecutableAndMissingSymbolFile [==] Running 1 test from 1 test case. [--]

[Lldb-commits] [PATCH] D86211: [lldb] Don't ask for QOS_CLASS_UNSPECIFIED queue in TestQueues

This revision was automatically updated to reflect the committed changes. Closed by commit rG7de7fe5d0e3f: [lldb] Don't ask for QOS_CLASS_UNSPECIFIED queue in TestQueues (authored by teemperor). Herald added a project: LLDB. Herald added a subscriber: lldb-commits. Repository: rG LLVM Github Mo

[Lldb-commits] [lldb] 7de7fe5 - [lldb] Don't ask for QOS_CLASS_UNSPECIFIED queue in TestQueues

Author: Raphael Isemann Date: 2020-08-25T20:13:33+02:00 New Revision: 7de7fe5d0e3f7f4d28e1dde42df4a7defa564f11 URL: https://github.com/llvm/llvm-project/commit/7de7fe5d0e3f7f4d28e1dde42df4a7defa564f11 DIFF: https://github.com/llvm/llvm-project/commit/7de7fe5d0e3f7f4d28e1dde42df4a7defa564f11.dif

[Lldb-commits] [lldb] ef76686 - [lldb] Initialize reproducers in LocateSymbolFileTest

Author: Raphael Isemann Date: 2020-08-25T20:26:43+02:00 New Revision: ef76686916d40f20c782ed3967130bd2e0105b31 URL: https://github.com/llvm/llvm-project/commit/ef76686916d40f20c782ed3967130bd2e0105b31 DIFF: https://github.com/llvm/llvm-project/commit/ef76686916d40f20c782ed3967130bd2e0105b31.dif

[Lldb-commits] [PATCH] D86389: [lldb] Add a SymbolFileProvider to record and replay calls to dsymForUUID

teemperor added a comment. Seems like this were just some missing calls to initialize/terminate. I added them in an ugly hotfix commit. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D86389/new/ https://reviews.llvm.org/D86389 _

[Lldb-commits] [PATCH] D86388: Fix use-after-free in ThreadPlan, and add test.

jingham added a comment. What's calling into the thread plans when WillResume has already been called? That seems wrong, since the thread list is in an uncertain state, having been cleared out for resume and not reset after the stop. It seems to me it would be a better fix to ensure that we a

[Lldb-commits] [lldb] 5212206 - [lldb] Make Reproducer compatbile with SubsystemRAII (NFC)

Author: Jonas Devlieghere Date: 2020-08-25T13:00:04-07:00 New Revision: 521220690ab7741e382344319b2a9d458be3eb41 URL: https://github.com/llvm/llvm-project/commit/521220690ab7741e382344319b2a9d458be3eb41 DIFF: https://github.com/llvm/llvm-project/commit/521220690ab7741e382344319b2a9d458be3eb41.d

[Lldb-commits] [PATCH] D86493: [lldb][NFC] Remove unused/misnamed SetObjectModificationTime

This revision was automatically updated to reflect the committed changes. Closed by commit rG66c48802918d: Remove unused/misnamed SetObjectModificationTime (authored by kastiglione). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D86493/new/ https://r

[Lldb-commits] [lldb] 66c4880 - Remove unused/misnamed SetObjectModificationTime

Author: Dave Lee Date: 2020-08-25T14:49:34-07:00 New Revision: 66c48802918d90e6a90d4f8da9c10889d5bc20dd URL: https://github.com/llvm/llvm-project/commit/66c48802918d90e6a90d4f8da9c10889d5bc20dd DIFF: https://github.com/llvm/llvm-project/commit/66c48802918d90e6a90d4f8da9c10889d5bc20dd.diff LOG:

[Lldb-commits] [PATCH] D85705: Add a "Trace" plug-in to LLDB to add process trace support in stages.

JDevlieghere added a comment. A large part of this patch is concerned with parsing which worries me from a maintenance perspective. Did you consider using Yaml I/O ? While I'm not a particularly big fan of the format, the benefits of being able to (de)serializ

[Lldb-commits] [PATCH] D86417: [lldb] do not propagate eTrapHandlerFrame repeatedly

jasonmolenda added a comment. Hi, I'll review this problem / suggested patch in a bit but I think it might be helpful to outline what the intention of all this is. Let's say we have a stack of frame #0 - handler_func() frame #1 - magic_function_called_from_kernel() frame #2 - doing_work(

[Lldb-commits] [PATCH] D85705: Add a "Trace" plug-in to LLDB to add process trace support in stages.

wallace added a comment. That's a very good idea! I'll revisit this patch then. I was not fond of doing the manual parsing but I hadn't found a more automated way. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D85705/new/ https://reviews.llvm.org/D

[Lldb-commits] [PATCH] D85705: Add a "Trace" plug-in to LLDB to add process trace support in stages.

clayborg requested changes to this revision. clayborg added a comment. This revision now requires changes to proceed. Looking better. The main thing we need to do it modify StructuredData classes a bit by moving a lot of the static functions we are using here into the appropriate classes. See in

[Lldb-commits] [PATCH] D85705: Add a "Trace" plug-in to LLDB to add process trace support in stages.

clayborg added a comment. After speaking with Walter a bit, key names in the JSON should be camel case. Many languages (Swift and JavaScript) can auto import JSON and create objects and use the key names as member variable names, and if they are camelCase, then no name conversion needs to happe

[Lldb-commits] [PATCH] D85705: Add a "Trace" plug-in to LLDB to add process trace support in stages.

clayborg added a comment. In D85705#2237397 , @JDevlieghere wrote: > A large part of this patch is concerned with parsing which worries me from a > maintenance perspective. Did you consider using Yaml I/O > ? While I'm

[Lldb-commits] [PATCH] D86388: Fix use-after-free in ThreadPlan, and add test.

comex added a comment. The sequence I found is: - `WillResume` - `DoResume` sends `eBroadcastBitAsyncContinue` to `ProcessGDBRemote::AsyncThread` - `AsyncThread` calls `process->SetPrivateState(eStateRunning);` - …which sends `eBroadcastBitStateChanged` back to the main thread, handled by `Proc

[Lldb-commits] [PATCH] D86417: [lldb] do not propagate eTrapHandlerFrame repeatedly

jasonmolenda added a comment. If I understand correctly, in frame #0: 0x004006bb a.out`handler(sig=6) at main.c:7:5 frame #1: 0x77a555a0 libc.so.6`__restore_rt frame #2: 0x77a55520 libc.so.6`raise + 272 frame #3: 0x77a56b01 libc.so.6`abort + 337 lldb think

[Lldb-commits] [PATCH] D86417: [lldb] do not propagate eTrapHandlerFrame repeatedly

jasonmolenda added a comment. separate from the fact that `UnwindPlan::Dump` does not print `m_plan_is_for_signal_trap` for an UnwindPlan, what we need to see from a real trap handler -- in lldb's terminology -- is that we have restore rules for all of the registers. If we're getting things ma

[Lldb-commits] [lldb] 99d187a - Update UnwindPlan dump to list if it is a trap handler func; also Command

Author: Jason Molenda Date: 2020-08-25T20:53:59-07:00 New Revision: 99d187a003c9bd4bdc42c17e5563bd80f4e159e9 URL: https://github.com/llvm/llvm-project/commit/99d187a003c9bd4bdc42c17e5563bd80f4e159e9 DIFF: https://github.com/llvm/llvm-project/commit/99d187a003c9bd4bdc42c17e5563bd80f4e159e9.diff

[Lldb-commits] [lldb] b1e856d - Ah, one test too many updated. This one should be unmodified.

Author: Jason Molenda Date: 2020-08-25T21:03:39-07:00 New Revision: b1e856d3a9019c355baa186075699d95be7b2735 URL: https://github.com/llvm/llvm-project/commit/b1e856d3a9019c355baa186075699d95be7b2735 DIFF: https://github.com/llvm/llvm-project/commit/b1e856d3a9019c355baa186075699d95be7b2735.diff

[Lldb-commits] [PATCH] D86417: [lldb] do not propagate eTrapHandlerFrame repeatedly

jasonmolenda added a comment. Minor followup on the 'image show-unwind' output -- I just landed a patch to print when a function or unwindplan are marked as being a trap handler. Repository: rLLDB LLDB CHANGES SINCE LAST ACTION https://reviews.llvm.org/D86417/new/ https://reviews.llvm.org