https://github.com/Michael137 edited
https://github.com/llvm/llvm-project/pull/95738
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -0,0 +1,165 @@
+(* LLDB Debug Expressions, a subset of C++ *)
+(* Insired by https://www.nongnu.org/hcb *)
+
+expression = assignment_expression ;
+
+assignment_expression = conditional_expression
+logical_or_expression assignment_operator
assignment_ex
https://github.com/Michael137 commented:
Haven't gone through this in detail yet (having an example of how these
structures will be used would be helpful), but something I was curious about is
whether this `DIL` is going to be used in the implementation of a new command,
or if we're going to e
@@ -0,0 +1,165 @@
+(* LLDB Debug Expressions, a subset of C++ *)
+(* Insired by https://www.nongnu.org/hcb *)
+
+expression = assignment_expression ;
+
+assignment_expression = conditional_expression
+logical_or_expression assignment_operator
assignment_ex
@@ -0,0 +1,165 @@
+(* LLDB Debug Expressions, a subset of C++ *)
+(* Insired by https://www.nongnu.org/hcb *)
+
+expression = assignment_expression ;
+
+assignment_expression = conditional_expression
+logical_or_expression assignment_operator
assignment_ex
@@ -0,0 +1,165 @@
+(* LLDB Debug Expressions, a subset of C++ *)
+(* Insired by https://www.nongnu.org/hcb *)
+
+expression = assignment_expression ;
+
+assignment_expression = conditional_expression
+logical_or_expression assignment_operator
assignment_ex
@@ -0,0 +1,165 @@
+(* LLDB Debug Expressions, a subset of C++ *)
+(* Insired by https://www.nongnu.org/hcb *)
+
+expression = assignment_expression ;
+
+assignment_expression = conditional_expression
+logical_or_expression assignment_operator
assignment_ex
https://github.com/Michael137 edited
https://github.com/llvm/llvm-project/pull/95738
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/Michael137 edited
https://github.com/llvm/llvm-project/pull/95738
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/Michael137 approved this pull request.
Nice, this is much more understandable, thanks!
https://github.com/llvm/llvm-project/pull/96308
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/l
AlexK0 wrote:
> Anyway, tl;dr, I believe this will fix it:
>
> ```
> --- a/lldb/source/Plugins/Process/Windows/Common/ProcessWindows.cpp
> +++ b/lldb/source/Plugins/Process/Windows/Common/ProcessWindows.cpp
> @@ -442,6 +442,7 @@ void ProcessWindows::RefreshStateAfterStop() {
> m_
Author: Pavel Labath
Date: 2024-06-24T13:35:16+02:00
New Revision: 41a4db1ba6591169069dd2352e00364d9113fbeb
URL:
https://github.com/llvm/llvm-project/commit/41a4db1ba6591169069dd2352e00364d9113fbeb
DIFF:
https://github.com/llvm/llvm-project/commit/41a4db1ba6591169069dd2352e00364d9113fbeb.diff
https://github.com/labath closed https://github.com/llvm/llvm-project/pull/96308
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Author: Pavel Labath
Date: 2024-06-24T14:16:24+02:00
New Revision: c053ec95f7e66ff212c8a867426cc7275a4dace6
URL:
https://github.com/llvm/llvm-project/commit/c053ec95f7e66ff212c8a867426cc7275a4dace6
DIFF:
https://github.com/llvm/llvm-project/commit/c053ec95f7e66ff212c8a867426cc7275a4dace6.diff
https://github.com/labath created
https://github.com/llvm/llvm-project/pull/96484
If ParseStructureLikeDIE (or ParseEnum) encountered a declaration DIE, it would
call FindDefinitionTypeForDIE. This returned a fully formed type, which it
achieved by recursing back into ParseStructureLikeDIE wit
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Pavel Labath (labath)
Changes
If ParseStructureLikeDIE (or ParseEnum) encountered a declaration DIE, it would
call FindDefinitionTypeForDIE. This returned a fully formed type, which it
achieved by recursing back into ParseStructureLikeDIE
labath wrote:
Hi there. Nice to see interest in this patch. Zequan has been OOO for the past
couple of weeks, so I've sort of taken this up in the mean time.
The problem with the simplified template names is actually already fixed (by
#95905), but in the mean time, I've discovered a very simil
https://github.com/Michael137 approved this pull request.
Makes sense to me
Do we make sure that the type lookup map is updated so we don't re-parse when
calling `ParseTypeFromDWARF` with either the declaration or the definition DIE?
https://github.com/llvm/llvm-project/pull/96484
_
https://github.com/labath updated
https://github.com/llvm/llvm-project/pull/96484
>From 52db8db036c24264647340c15ec4ee6d3553cf60 Mon Sep 17 00:00:00 2001
From: Pavel Labath
Date: Mon, 24 Jun 2024 11:17:47 +0200
Subject: [PATCH 1/2] [lldb/DWARF] Remove parsing recursion when searching for
defin
labath wrote:
> Makes sense to me Do we make sure that the type lookup map is updated so we
> don't re-parse when calling `ParseTypeFromDWARF` with either the declaration
> or the definition DIE?
Good catch. I've been meaning to add that, but I forgot. Things should still
work even without th
Michael137 wrote:
Latest update LGTM
https://github.com/llvm/llvm-project/pull/96484
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Author: Miro Bucko
Date: 2024-06-24T11:06:20-04:00
New Revision: 10bd5ad0a133fe73ffc1b05e63bc3fb2d56ba79c
URL:
https://github.com/llvm/llvm-project/commit/10bd5ad0a133fe73ffc1b05e63bc3fb2d56ba79c
DIFF:
https://github.com/llvm/llvm-project/commit/10bd5ad0a133fe73ffc1b05e63bc3fb2d56ba79c.diff
LO
https://github.com/mbucko closed https://github.com/llvm/llvm-project/pull/95007
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -216,6 +228,35 @@ u64 GetShadowCount(uptr p, u32 size) {
return count;
}
+// Accumulates the access count from the shadow for the given pointer and size.
+// See memprof_mapping.h for an overview on histogram counters.
+u64 GetShadowCountHistogram(uptr p, u32 size) {
+ u
@@ -216,6 +228,35 @@ u64 GetShadowCount(uptr p, u32 size) {
return count;
}
+// Accumulates the access count from the shadow for the given pointer and size.
+// See memprof_mapping.h for an overview on histogram counters.
+u64 GetShadowCountHistogram(uptr p, u32 size) {
+ u
@@ -38,4 +38,5 @@ MEMPROF_FLAG(bool,
allocator_frees_and_returns_null_on_realloc_zero, true,
MEMPROF_FLAG(bool, print_text, false,
"If set, prints the heap profile in text format. Else use the raw binary
serialization format.")
MEMPROF_FLAG(bool, print_terse, false,
-
@@ -205,8 +205,14 @@ class RawMemProfReader final : public MemProfReader {
object::SectionedAddress getModuleOffset(uint64_t VirtualAddress);
+ llvm::SmallVector>
+ readMemInfoBlocks(const char *Ptr);
+
// The profiled binary.
object::OwningBinary Binary;
+ // Vers
@@ -96,19 +102,63 @@ llvm::SmallVector readSegmentEntries(const
char *Ptr) {
}
llvm::SmallVector>
-readMemInfoBlocks(const char *Ptr) {
+readMemInfoBlocksV3(const char *Ptr) {
using namespace support;
const uint64_t NumItemsToRead =
- endian::readNext(Ptr);
+
@@ -610,13 +670,33 @@ RawMemProfReader::peekBuildIds(MemoryBuffer *DataBuffer) {
return BuildIds.takeVector();
}
+// FIXME: Add a schema for serializing similiar to IndexedMemprofReader. This
+// will help being able to deserialize different versions raw memprof versions
+//
@@ -508,7 +519,26 @@ void createProfileFileNameVar(Module &M) {
}
}
+// Set MemprofHistogramFlag as a Global veriable in IR. This makes it
accessible
+// to
mattweingarten wrote:
done.
https://github.com/llvm/llvm-project/pull/94264
__
@@ -508,7 +519,26 @@ void createProfileFileNameVar(Module &M) {
}
}
+// Set MemprofHistogramFlag as a Global veriable in IR. This makes it
accessible
+// to
+// the runtime, changing shadow count behavior.
+void createMemprofHistogramFlagVar(Module &M) {
+ const StringRef
@@ -0,0 +1,101 @@
+REQUIRES: x86_64-linux
+
+This is a copy of memprof-basict.test with slight changes to check that we can
still read v3 of memprofraw.
mattweingarten wrote:
done
https://github.com/llvm/llvm-project/pull/94264
_
@@ -0,0 +1,101 @@
+REQUIRES: x86_64-linux
+
+This is a copy of memprof-basict.test with slight changes to check that we can
still read v3 of memprofraw.
+
+To update the inputs used below run Inputs/update_memprof_inputs.sh
/path/to/updated/clang
mattweingarten
@@ -20,25 +20,25 @@ CHECK-NEXT: -
CHECK: Records:
CHECK-NEXT: -
-CHECK-NEXT:FunctionGUID: 15505678318020221912
+CHECK-NEXT:FunctionGUID: 3873612792189045660
CHECK-NEXT:AllocSites:
CHECK-NEXT:-
CHECK-NEXT: Callstack:
CHECK-NEXT: -
-CHECK-NEXT:
@@ -124,6 +124,13 @@ struct PortableMemInfoBlock {
OS << "" << #Name << ": " << Name << "\n";
#include "llvm/ProfileData/MIBEntryDef.inc"
#undef MIBEntryDef
+if (AccessHistogramSize > 0) {
+ OS << "" << "AccessHistogramValues" << ":";
+ for (uint
dwblaikie wrote:
This patch as-is is NFC? (no tests) but without this patch, the other
delay-definition-die patch would have had a problem?
Is it possible to add a test in this patch that would exercise the thing that
would become buggy if the delay-definition-die patch were to be recommitted?
chelcassanova wrote:
Hey Miro, looks like this change broke the LLDB MacOS buildbot:
https://green.lab.llvm.org/job/llvm.org/view/LLDB/job/as-lldb-cmake/6353/
https://github.com/llvm/llvm-project/pull/95007
___
lldb-commits mailing list
lldb-commits@l
https://github.com/mbucko created
https://github.com/llvm/llvm-project/pull/96511
Tests added in #95007.
>From 4f5588a6928080833a428fc7e1356a807a333a0e Mon Sep 17 00:00:00 2001
From: Miro Bucko
Date: Mon, 24 Jun 2024 09:15:36 -0700
Subject: [PATCH] [lldb] Fix TestFind(Ranges)InMemory.py tests.
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Miro Bucko (mbucko)
Changes
Tests added in #95007.
---
Full diff: https://github.com/llvm/llvm-project/pull/96511.diff
1 Files Affected:
- (modified) lldb/test/API/python_api/find_in_memory/address_ranges_helper.py
(-1)
``dif
https://github.com/JDevlieghere approved this pull request.
Looks like this is to unblock the bots? Is the test actually incorrect or is
this a temporary fix while you investigate? Would be nice to mention that in
the commit message.
https://github.com/llvm/llvm-project/pull/96511
___
https://github.com/mbucko edited https://github.com/llvm/llvm-project/pull/96511
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Author: Chelsea Cassanova
Date: 2024-06-24T09:50:42-07:00
New Revision: 347206f9570446340da6d7dadc13d10b0aac4528
URL:
https://github.com/llvm/llvm-project/commit/347206f9570446340da6d7dadc13d10b0aac4528
DIFF:
https://github.com/llvm/llvm-project/commit/347206f9570446340da6d7dadc13d10b0aac4528.d
https://github.com/chelcassanova closed
https://github.com/llvm/llvm-project/pull/96001
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/clayborg updated
https://github.com/llvm/llvm-project/pull/87740
>From 3f99b41eac0e04e15bdb99bea2ee75703936ea00 Mon Sep 17 00:00:00 2001
From: Greg Clayton
Date: Sat, 30 Mar 2024 10:50:34 -0700
Subject: [PATCH 01/12] Add support for using foreign type units in
.debug_names.
Author: Greg Clayton
Date: 2024-06-24T09:59:59-07:00
New Revision: 3b5b814647ef83ab763cf7871b6d74edfca67438
URL:
https://github.com/llvm/llvm-project/commit/3b5b814647ef83ab763cf7871b6d74edfca67438
DIFF:
https://github.com/llvm/llvm-project/commit/3b5b814647ef83ab763cf7871b6d74edfca67438.diff
https://github.com/clayborg closed
https://github.com/llvm/llvm-project/pull/87740
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Author: Greg Clayton
Date: 2024-06-24T10:16:39-07:00
New Revision: fc066ca1c32b4aef549f3e371dc70589804aba0f
URL:
https://github.com/llvm/llvm-project/commit/fc066ca1c32b4aef549f3e371dc70589804aba0f
DIFF:
https://github.com/llvm/llvm-project/commit/fc066ca1c32b4aef549f3e371dc70589804aba0f.diff
clayborg wrote:
An extra character snuck in and messed with the buildbots, fixed with:
```
commit fc066ca1c32b4aef549f3e371dc70589804aba0f (HEAD -> main, origin/main,
origin/HEAD)
Author: Greg Clayton
Date: Mon Jun 24 10:15:55 2024 -0700
Fix buildbots for https://github.com/llvm/llvm-pro
https://github.com/mattweingarten updated
https://github.com/llvm/llvm-project/pull/94264
error: too big or took too long to generate
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/mattweingarten edited
https://github.com/llvm/llvm-project/pull/94264
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Author: Jacob Lalonde
Date: 2024-06-24T10:48:01-07:00
New Revision: a27164cb33162bb42642c091703f9c6f8829785c
URL:
https://github.com/llvm/llvm-project/commit/a27164cb33162bb42642c091703f9c6f8829785c
DIFF:
https://github.com/llvm/llvm-project/commit/a27164cb33162bb42642c091703f9c6f8829785c.diff
https://github.com/clayborg closed
https://github.com/llvm/llvm-project/pull/95312
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Author: Miro Bucko
Date: 2024-06-24T11:38:05-07:00
New Revision: 33a9c57b89c3ea901a057c3fcc9c9160eaf5a625
URL:
https://github.com/llvm/llvm-project/commit/33a9c57b89c3ea901a057c3fcc9c9160eaf5a625
DIFF:
https://github.com/llvm/llvm-project/commit/33a9c57b89c3ea901a057c3fcc9c9160eaf5a625.diff
LO
https://github.com/JDevlieghere closed
https://github.com/llvm/llvm-project/pull/96511
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
labath wrote:
> This patch as-is is NFC?
NFC**I**, I would say :) I don't think this should change the behavior in any
way, but it's pretty hard to guarantee that.
> (no tests) but without this patch, the other delay-definition-die patch would
> have had a problem?
>
> Is it possible to add a
https://github.com/oontvoo updated
https://github.com/llvm/llvm-project/pull/95571
>From 018c7a6052add708e0b0d09b911a904b52199da5 Mon Sep 17 00:00:00 2001
From: Vy Nguyen
Date: Tue, 11 Jun 2024 14:15:43 -0400
Subject: [PATCH 1/5] Reapply "Reapply PR/87550 (#94625)"
This reverts commit adcf33f8
@@ -65,16 +58,67 @@ DAP::DAP()
DAP::~DAP() = default;
+void DAP::PopulateExceptionBreakpoints() {
+ llvm::call_once(initExceptionBreakpoints, [this]() {
+exception_breakpoints = std::vector {};
+
+if (lldb::SBDebugger::SupportsLanguage(lldb::eLanguageTypeC_plus_p
https://github.com/Michael137 created
https://github.com/llvm/llvm-project/pull/96538
This patch is in preparation for the `__compressed_pair` refactor in
https://github.com/llvm/llvm-project/pull/76756.
This gets the formatter tests to at least pass.
Currently in draft because there's still
dwblaikie wrote:
> > This patch as-is is NFC?
>
> NFC_**I**_, I would say :) I don't think this should change the behavior in
> any way, but it's pretty hard to guarantee that.
Sure enough - I take any claim as a statement of intent/belief, not of
something mathematically proved, etc.
> > (n
github-actions[bot] wrote:
:warning: Python code formatter, darker found issues in your code. :warning:
You can test this locally with the following command:
``bash
darker --check --diff -r
62baf21daa377c4ec1a641b26931063c1117d262...3b4d9629a68c9e75dfd139ee2745bf00db979ecd
lldb/
llvm-ci wrote:
LLVM Buildbot has detected a new failure on builder `llvm-x86_64-debian-dylib`
running on `gribozavr4` while building `lldb,llvm` at step 5
"build-unified-tree".
Full details are available at:
https://lab.llvm.org/buildbot/#/builders/60/builds/803
Here is the relevant piece of
petrhosek wrote:
This broke the Windows build with the following error:
```
C:\b\s\w\ir\x\w\cipd\bin\clang-cl.exe /nologo -TP -DGTEST_HAS_RTTI=0
-DLIBXML_STATIC -DUNICODE -D_CRT_NONSTDC_NO_DEPRECATE
-D_CRT_NONSTDC_NO_WARNINGS -D_CRT_SECURE_NO_DEPRECATE -D_CRT_SECURE_NO_WARNINGS
-D_ENABLE_EXTE
https://github.com/chelcassanova created
https://github.com/llvm/llvm-project/pull/96560
Reverting to unblock macOS buildbots which are currently failing on these
tests. https://green.lab.llvm.org/job/llvm.org/view/LLDB/job/as-lldb-cmake/6377/
>From 22127178761968b01be207a1c83c7048dc3ec47d Mon
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Chelsea Cassanova (chelcassanova)
Changes
Reverting to unblock macOS buildbots which are currently failing on these
tests. https://green.lab.llvm.org/job/llvm.org/view/LLDB/job/as-lldb-cmake/6377/
---
Patch is 28.12 KiB, truncated to 20.0
Jlalond wrote:
@petrhosek because it's just going to be a change to something like `size_t`,
would you mind if I just did a quick commit to fix this and assign you as the
reviewer?
https://github.com/llvm/llvm-project/pull/95312
___
lldb-commits mai
https://github.com/Jlalond created
https://github.com/llvm/llvm-project/pull/96564
In !95312 I incorrectly set `m_expected_directories` to uint, this broke the
windows build and is the incorrect type.
`size_t` is more accurate because this value only ever represents the expected
upper bound
https://github.com/Jlalond edited
https://github.com/llvm/llvm-project/pull/96564
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Jacob Lalonde (Jlalond)
Changes
In !95312 I incorrectly set `m_expected_directories` to uint, this broke the
windows build and is the incorrect type.
`size_t` is more accurate because this value only ever represents the expected
upper bo
https://github.com/petrhosek approved this pull request.
Thanks for a quick fix!
https://github.com/llvm/llvm-project/pull/96564
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/mbucko created
https://github.com/llvm/llvm-project/pull/96565
None
>From b19c3daa8eb513eac9de77f9348b25035bdd9697 Mon Sep 17 00:00:00 2001
From: Miro Bucko
Date: Mon, 24 Jun 2024 17:54:05 -0400
Subject: [PATCH] [lldb] Fix tests for FindInMemory SB API introduced in
#95007.
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Miro Bucko (mbucko)
Changes
---
Full diff: https://github.com/llvm/llvm-project/pull/96565.diff
3 Files Affected:
- (modified) lldb/test/API/python_api/find_in_memory/TestFindInMemory.py
(+24-1)
- (modified) lldb/test/API/python_api/f
Author: Chelsea Cassanova
Date: 2024-06-24T15:12:49-07:00
New Revision: a32b7199f0c15ea1c6c9490b6166c019c9d4bd2b
URL:
https://github.com/llvm/llvm-project/commit/a32b7199f0c15ea1c6c9490b6166c019c9d4bd2b
DIFF:
https://github.com/llvm/llvm-project/commit/a32b7199f0c15ea1c6c9490b6166c019c9d4bd2b.d
https://github.com/chelcassanova closed
https://github.com/llvm/llvm-project/pull/96560
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/bulbazord commented:
I'm a bit late to the party, I was out sick last week. :p
I think I understand this change and it looks fine to me overall.
One thing I noticed is that a lot of things that could be considered errors are
only written to the logs and then are silently glos
https://github.com/bulbazord edited
https://github.com/llvm/llvm-project/pull/95768
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -4179,21 +4179,124 @@ struct GdbServerTargetInfo {
RegisterSetMap reg_set_map;
};
-static std::vector ParseFlagsFields(XMLNode flags_node,
- unsigned size) {
+static FieldEnum::Enumerators ParseEnumEvalues(const XML
https://github.com/shawbyoung edited
https://github.com/llvm/llvm-project/pull/95821
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/clayborg commented:
Just add a description to what this test had wrong, what is fixed and any other
needed details and this should be good to go
https://github.com/llvm/llvm-project/pull/96565
___
lldb-commits mailing list
lldb-comm
https://github.com/shawbyoung updated
https://github.com/llvm/llvm-project/pull/95821
>From 9452bd574023a7aef75b609d36e0ffac68e1e03d Mon Sep 17 00:00:00 2001
From: Sayhaan Siddiqui
Date: Mon, 17 Jun 2024 11:11:07 -0700
Subject: [PATCH 01/21] =?UTF-8?q?[=F0=9D=98=80=F0=9D=97=BD=F0=9D=97=BF]=20?=
https://github.com/shawbyoung closed
https://github.com/llvm/llvm-project/pull/95821
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/Jlalond edited
https://github.com/llvm/llvm-project/pull/96564
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Jlalond wrote:
Fixed uint issue in #96564
https://github.com/llvm/llvm-project/pull/95312
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/mbucko closed https://github.com/llvm/llvm-project/pull/96565
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
llvm-ci wrote:
LLVM Buildbot has detected a new failure on builder `bolt-x86_64-ubuntu-shared`
running on `bolt-worker` while building `bolt` at step 5 "build-bolt".
Full details are available at:
https://lab.llvm.org/buildbot/#/builders/151/builds/367
Here is the relevant piece of the build
https://github.com/mbucko created
https://github.com/llvm/llvm-project/pull/96569
This is a second attempt to land #95007
Test Plan:
llvm-lit
llvm-project/lldb/test/API/python_api/find_in_memory/TestFindInMemory.py
llvm-project/lldb/test/API/python_api/find_in_memory/TestFindRangesInMemory.py
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Miro Bucko (mbucko)
Changes
This is a second attempt to land #95007
Test Plan:
llvm-lit
llvm-project/lldb/test/API/python_api/find_in_memory/TestFindInMemory.py
llvm-project/lldb/test/API/python_api/find_in_memory/TestFindRangesInMemory.p
https://github.com/mbucko updated
https://github.com/llvm/llvm-project/pull/96569
>From 6b1720e9e93d20eecbade7d63d8c2ae5e671c440 Mon Sep 17 00:00:00 2001
From: Miro Bucko
Date: Tue, 4 Jun 2024 12:01:48 -0700
Subject: [PATCH] [lldb][API] Add Find(Ranges)InMemory() to Process SB API
This is a se
https://github.com/clayborg approved this pull request.
https://github.com/llvm/llvm-project/pull/96569
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Author: Miro Bucko
Date: 2024-06-24T18:51:12-04:00
New Revision: 0d4da0df166ea7512c6e97e182b21cd706293eaa
URL:
https://github.com/llvm/llvm-project/commit/0d4da0df166ea7512c6e97e182b21cd706293eaa
DIFF:
https://github.com/llvm/llvm-project/commit/0d4da0df166ea7512c6e97e182b21cd706293eaa.diff
LO
https://github.com/mbucko closed https://github.com/llvm/llvm-project/pull/96569
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
jasonmolenda wrote:
Thanks @AlexK0 ! After Pavel's suggestion, I need to do a minor bit of changes
to the patch soon I think, for all platforms, so I'll see if this is easier to
express in ProcessWindows that way.
I've was thinking about @labath 's suggestion over the weekend and I agree that
Author: Jacob Lalonde
Date: 2024-06-24T16:33:09-07:00
New Revision: 361543e4100defe14334cfb11481be44a977e627
URL:
https://github.com/llvm/llvm-project/commit/361543e4100defe14334cfb11481be44a977e627
DIFF:
https://github.com/llvm/llvm-project/commit/361543e4100defe14334cfb11481be44a977e627.diff
https://github.com/Jlalond closed
https://github.com/llvm/llvm-project/pull/96564
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -216,6 +228,35 @@ u64 GetShadowCount(uptr p, u32 size) {
return count;
}
+// Accumulates the access count from the shadow for the given pointer and size.
+// See memprof_mapping.h for an overview on histogram counters.
+u64 GetShadowCountHistogram(uptr p, u32 size) {
+ u
@@ -96,19 +102,63 @@ llvm::SmallVector readSegmentEntries(const
char *Ptr) {
}
llvm::SmallVector>
-readMemInfoBlocks(const char *Ptr) {
+readMemInfoBlocksV3(const char *Ptr) {
using namespace support;
const uint64_t NumItemsToRead =
- endian::readNext(Ptr);
+
@@ -20,25 +20,25 @@ CHECK-NEXT: -
CHECK: Records:
CHECK-NEXT: -
-CHECK-NEXT:FunctionGUID: 15505678318020221912
+CHECK-NEXT:FunctionGUID: 3873612792189045660
CHECK-NEXT:AllocSites:
CHECK-NEXT:-
CHECK-NEXT: Callstack:
CHECK-NEXT: -
-CHECK-NEXT:
cmtice wrote:
> Haven't gone through this in detail yet (having an example of how these
> structures will be used would be helpful), but something I was curious about
> is whether this `DIL` is going to be used in the implementation of a new
> command, or if we're going to extend the `frame va
vvereschaka wrote:
Hi @Jlalond ,
here is still a problem with the window builds:
```
FAILED:
tools/lldb/source/Plugins/ObjectFile/Minidump/CMakeFiles/lldbPluginObjectFileMinidump.dir/ObjectFileMinidump.cpp.obj
ccache C:\PROGRA~1\LLVM\bin\clang-cl.exe /nologo -TP -DGTEST_HAS_RTTI=0
-DUNICODE
https://github.com/labath approved this pull request.
https://github.com/llvm/llvm-project/pull/95571
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
labath wrote:
Thanks for the explanation, Jason. I believe I understand the problem now.
Here, we're concerned with whether the physical breakpoint opcode got executed,
and not about the higher level machinery (conditional breakpoints, ignore
count, ...), which builds on top of that and can ca
100 matches
Mail list logo
