[Lldb-commits] [lldb] 852a4bd - Change the Sanitizer report breakpoint callbacks to asynchronous.

Author: Jim Ingham Date: 2022-10-03T18:10:28-07:00 New Revision: 852a4bdb25d145884f61cd812e66611e65fd2dd9 URL: https://github.com/llvm/llvm-project/commit/852a4bdb25d145884f61cd812e66611e65fd2dd9 DIFF: https://github.com/llvm/llvm-project/commit/852a4bdb25d145884f61cd812e66611e65fd2dd9.diff

[Lldb-commits] [PATCH] D134927: Make the sanitizer Notify callbacks asynchronous

This revision was automatically updated to reflect the committed changes. Closed by commit rG852a4bdb25d1: Change the Sanitizer report breakpoint callbacks to asynchronous. (authored by jingham). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION

[Lldb-commits] [PATCH] D126668: LLDB: Fix resolving nested template parameters

dblaikie added a comment. FWIW, clang has support for including template parameter DIEs for template declarations (-Xclang -debug-forward-template-params). We could enable that by default when tuning for lldb (or maybe we're at the tipping point and we should enable it by default in general -

[Lldb-commits] [PATCH] D134842: Improve dynamic loader support in DynamicLoaderPOSIXDYLD when using core files.

aadsm added a comment. Would it be possible to have a test for this? We would have probably found this, if we had a test at the time I rewrote this logic. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D134842/new/ https://reviews.llvm.org/D134842

[Lldb-commits] [PATCH] D134991: [lldb] Add diagnostics

JDevlieghere added a comment. In D134991#3830682 , @DavidSpickett wrote: > I like the direction, thanks for working on this. > > To no one's surprise, I was thinking about testing :) > > - Errors related to the filesystem e.g. can't open a path, is too

[Lldb-commits] [PATCH] D134882: [lldb] Move breakpoint hit reset code to Target::CleanupProcess

jingham added a comment. That seems fine. I think it's useful to be able to see breakpoint hit counts up to the point where you start a new process. From looking at the code, it looks like putting the clear in CleanupProcess will do that. If you agree this is useful, can you add to the test

[Lldb-commits] [PATCH] D135028: [lldb] [gdb-remote] Move ReadPacketWithOutputSupport() to client

This revision was automatically updated to reflect the committed changes. Closed by commit rGb6c24c161900: [lldb] [gdb-remote] Move ReadPacketWithOutputSupport() to client (authored by mgorny). Herald added a project: LLDB. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION

[Lldb-commits] [lldb] b6c24c1 - [lldb] [gdb-remote] Move ReadPacketWithOutputSupport() to client

Author: Michał Górny Date: 2022-10-03T18:42:49+02:00 New Revision: b6c24c161900a035f5ea7193f4816b6d192d6ac8 URL: https://github.com/llvm/llvm-project/commit/b6c24c161900a035f5ea7193f4816b6d192d6ac8 DIFF: https://github.com/llvm/llvm-project/commit/b6c24c161900a035f5ea7193f4816b6d192d6ac8.diff

[Lldb-commits] [PATCH] D134906: Have MemoryCache cache addresses that were unreadable, so duplicate read attempts can be suppressed

jasonmolenda added a comment. Jim & David, thanks so much for the comments. The most important question of correctness that David asks is whether we might try to read 32k from an address and mark that address as inaccessible because a page 24k into the memory read failed (for instance). I

[Lldb-commits] [PATCH] D135029: [lldb] [gdb-remote] Isolate ClientBase from Communication

mgorny added inline comments. Comment at: lldb/source/Plugins/Process/gdb-remote/GDBRemoteClientBase.h:116-118 + GDBRemoteCommunication () { +return m_comm; + } labath wrote: > Is the plan to make this private/protected at some point, or something like >

[Lldb-commits] [PATCH] D134882: [lldb] Move breakpoint hit reset code to Target::CleanupProcess

labath added a comment. Here's an even better idea. I've now doing it in Target::CleanupProcess, right next to the code for resetting **watch**point hit counts. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D134882/new/

[Lldb-commits] [PATCH] D134882: [lldb] Move breakpoint hit reset code to Target::CreateProcess

labath updated this revision to Diff 464700. labath added a comment. use CleanupProcess instead Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D134882/new/ https://reviews.llvm.org/D134882 Files: lldb/source/Target/Process.cpp

[Lldb-commits] [PATCH] D134656: [LLDB][NativePDB] Add class/union layout bit size.

labath added a comment. In D134656#3819025 , @zequanwu wrote: >>> For members from parent classes, pdb only has information saying that its >>> direct parents class are at some offsets for this class. For class without >>> vtable, it's easy to

[Lldb-commits] [PATCH] D135029: [lldb] [gdb-remote] Isolate ClientBase from Communication

labath added inline comments. Comment at: lldb/source/Plugins/Process/gdb-remote/GDBRemoteClientBase.h:116-118 + GDBRemoteCommunication () { +return m_comm; + } Is the plan to make this private/protected at some point, or something like that? Otherwise,

[Lldb-commits] [PATCH] D134991: [lldb] Add diagnostics

labath added a subscriber: rupprecht. labath added a comment. Adding @rupprecht, as he might be interested in following this. I don't want to get too involved in this, but the first thought on my mind is "do you really want to do all this from within a signal handler?". The fact that we're

[Lldb-commits] [PATCH] D134991: [lldb] Add diagnostics

DavidSpickett added a comment. I like the direction, thanks for working on this. To no one's surprise, I was thinking about testing :) - Errors related to the filesystem e.g. can't open a path, is too complicated to setup on demand. The code looks to be passing on the error, which is good

[Lldb-commits] [PATCH] D133778: Fix LLDB build on old Linux kernels (pre-4.1)

DavidSpickett added a comment. I only have newer kernels but replacing the type with what it looks like on an older kernel and undefing PERF_ATTR_SIZE_VER5, lldb does build. So it looks like this is a good thing to land. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION

[Lldb-commits] [PATCH] D134906: Have MemoryCache cache addresses that were unreadable, so duplicate read attempts can be suppressed

DavidSpickett added a comment. > If we wanted to track these decisions it would be more appropriate to log > them, but I'm not sure even that is necessary. Yeah this is a better idea, if we do it at all. Let me rephrase the question. If I had a memory read failing and I suspected that the

[Lldb-commits] [PATCH] D133778: Fix LLDB build on old Linux kernels (pre-4.1)

DavidSpickett added a comment. Did this ever land? I only see https://github.com/llvm/llvm-project/commit/d35702efe73010409c75b1f1b64f205cc3b2f6d3. We have a short time to get this into 15.0.2, so I'd like to land this if it is needed. Repository: rG LLVM Github Monorepo CHANGES SINCE