vvereschaka wrote:
This build got the same failed test on the windows host -
https://lab.llvm.org/buildbot/#/builders/141/builds/318
```
Failed Tests (1):
lldb-shell :: SymbolFile/DWARF/x86/dwp-foreign-type-units.cpp
```
```
# .---command stderr
# |
C:\Users\tcwg\llvm-worker\lld
https://github.com/Jlalond closed
https://github.com/llvm/llvm-project/pull/96724
___
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-25T21:26:31-07:00
New Revision: cb3469a30f875b9cd54a263803fffc93554bec12
URL:
https://github.com/llvm/llvm-project/commit/cb3469a30f875b9cd54a263803fffc93554bec12
DIFF:
https://github.com/llvm/llvm-project/commit/cb3469a30f875b9cd54a263803fffc93554bec12.diff
https://github.com/vvereschaka approved this pull request.
LGTM.
https://github.com/llvm/llvm-project/pull/96724
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
vvereschaka wrote:
Thank you @Jlalond , I started checking the local builds on Windows/Linux hosts
with these changes.
https://github.com/llvm/llvm-project/pull/96724
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi
Jlalond wrote:
Hey @petrhosek @vvereschaka apologies about the delay, I had to get a Windows
machine up to validate this.
https://github.com/llvm/llvm-project/pull/96724
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Jacob Lalonde (Jlalond)
Changes
In #95312 uint and `#include ` were introduced. These
broke the windows build. I addressed uint i
https://github.com/Jlalond created
https://github.com/llvm/llvm-project/pull/96724
In #95312 uint and `#include ` were introduced. These broke the
windows build. I addressed uint in #96564, but
JDevlieghere wrote:
> Sounds reasonable. I'll work that out with a helper method and resend for
> review once I upload a new commit. @bulbazord any idea how I can access the
> module from the `SBThread` object, to compare it against the name `a.out`?
> I'm having trouble finding the right API.
@@ -897,32 +895,39 @@ TypeSP DWARFASTParserClang::ParseEnum(const SymbolContext
&sc,
}
CompilerType clang_type = m_ast.CreateEnumerationType(
- attrs.name.GetStringRef(), GetClangDeclContextContainingDIE(die,
nullptr),
- GetOwningClangModule(die), attrs.decl, e
Jlalond wrote:
@petrhosek I am working on this. I think it's only the header thankfully
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-commi
kendalharland wrote:
> Instead of assuming the thread's index or index ID, it might be a good idea
> to have a little helper method that can look through the inferior's threads
> to find the thread with the property that we care about. In this case, we're
> looking for the thread that's stoppe
https://github.com/bulbazord edited
https://github.com/llvm/llvm-project/pull/96685
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/bulbazord requested changes to this pull request.
Instead of assuming the thread's index or index ID, it might be a good idea to
have a little helper method that can look through the inferior's threads to
find the thread with the property that we care about. In this case, we'
bulbazord wrote:
One option might be to change the test to match against some list of expected
strings. I'm not super familiar with this test but as Jeffrey said this could
be OS/Platform dependent.
https://github.com/llvm/llvm-project/pull/96687
___
https://github.com/jeffreytan81 requested changes to this pull request.
Have you tried to run this test on Linux? It is passing on my machine. I am
pretty sure this might be Windows platform (like compiler and disassembler)
specific behavior which you shouldn't change the default value for the
https://github.com/kendalharland edited
https://github.com/llvm/llvm-project/pull/96685
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/kendalharland edited
https://github.com/llvm/llvm-project/pull/96685
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/kendalharland edited
https://github.com/llvm/llvm-project/pull/96685
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/kendalharland edited
https://github.com/llvm/llvm-project/pull/96685
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/kendalharland updated
https://github.com/llvm/llvm-project/pull/96685
>From 97242b723de7fd4dcb14bd8481acc2254ab852ea Mon Sep 17 00:00:00 2001
From: kendal
Date: Mon, 24 Jun 2024 13:42:20 -0700
Subject: [PATCH] Fix flake in TestZerothFrame.py
This test is relying on the order
kendalharland wrote:
This PR was really just the result of me looking at the test output on my own
machine and copy-pasting the values that were generated by the test's data. I
am not familiar with this test's implementation and would appreciate any
guidance on whether there really is a bug he
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Kendal Harland (kendalharland)
Changes
The strings this test is using seem to consistently fail to match against the
expected values when built & run targeting Windows amd64. This PR updates
them to the expected values.
---
Full diff: htt
github-actions[bot] wrote:
Thank you for submitting a Pull Request (PR) to the LLVM Project!
This PR will be automatically labeled and the relevant teams will be
notified.
If you wish to, you can add reviewers by using the "Reviewers" section on this
page.
If this is not working for you, it
https://github.com/kendalharland created
https://github.com/llvm/llvm-project/pull/96687
The strings this test is using seem to consistently fail to match against the
expected values when built & run targeting Windows amd64. This PR updates them
to the expected values.
>From 2e3ac00255e5608ff
https://github.com/kendalharland edited
https://github.com/llvm/llvm-project/pull/96685
___
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: Kendal Harland (kendalharland)
Changes
This test is currently flaky on a local Windows amd64 build.
If we print lldb's inputs and outputs while running, we can see that the
breakpoints are always being set correctly, and always being hit:
github-actions[bot] wrote:
Thank you for submitting a Pull Request (PR) to the LLVM Project!
This PR will be automatically labeled and the relevant teams will be
notified.
If you wish to, you can add reviewers by using the "Reviewers" section on this
page.
If this is not working for you, it
https://github.com/kendalharland created
https://github.com/llvm/llvm-project/pull/96685
This test is currently flaky on a local Windows amd64 build.
If we print lldb's inputs and outputs while running, we can see that the
breakpoints are always being set correctly, and always being hit:
```s
petrhosek wrote:
We're seeing the same issue as well on our builders, will you be able to
address this today?
https://github.com/llvm/llvm-project/pull/95312
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mail
https://github.com/teresajohnson approved this pull request.
lgtm
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
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
@@ -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
https://github.com/Michael137 closed
https://github.com/llvm/llvm-project/pull/96635
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Author: Michael Buch
Date: 2024-06-25T19:05:16+01:00
New Revision: 21ab32e1c144b42458b7b3181e84bfb45aadcc54
URL:
https://github.com/llvm/llvm-project/commit/21ab32e1c144b42458b7b3181e84bfb45aadcc54
DIFF:
https://github.com/llvm/llvm-project/commit/21ab32e1c144b42458b7b3181e84bfb45aadcc54.diff
@@ -97,6 +101,9 @@ def finalize_build_dictionary(dictionary):
dictionary = {}
dictionary["OS"] = "Android"
dictionary["PIE"] = 1
+elif target_is_remote_linux():
+dictionary = dictionary or {}
bulbazord wrote:
Suggestion:
https://github.com/bulbazord approved this pull request.
Oh, yeah, that makes a lot more sense.
https://github.com/llvm/llvm-project/pull/96635
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/ll
labath wrote:
It looks like the test is flaky:
https://lab.llvm.org/buildbot/#/builders/59/builds/535
It looks like the order of the types is nondeterministic. I think you should be
able to use CHECK-DAG along with [this trick to match
newlines](https://llvm.org/docs/CommandGuide/FileChec
vvereschaka wrote:
@Jlalond , perfect, thank you. It is ok for me if you'll fix the problem during
today.
https://github.com/llvm/llvm-project/pull/95312
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/
Jlalond wrote:
@vvereschaka I'll work on this today. Is it time pressing enough you would want
everything reverted?
https://github.com/llvm/llvm-project/pull/95312
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bi
walter-erquinigo wrote:
I second everything that Pavel says. I think this would be the best approach.
The existing frame var implementation is not that "smart", so it should be
practical to fully replace it with the new DIL in its first stage.
An additional consideration is that lldb-dap, whic
https://github.com/oontvoo closed
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
Author: Vy Nguyen
Date: 2024-06-25T12:01:17-04:00
New Revision: e951bd0f51f8b077296f09d9c60ddf150048042f
URL:
https://github.com/llvm/llvm-project/commit/e951bd0f51f8b077296f09d9c60ddf150048042f
DIFF:
https://github.com/llvm/llvm-project/commit/e951bd0f51f8b077296f09d9c60ddf150048042f.diff
LOG
dzhidzhoev wrote:
Closed in favor of https://github.com/llvm/llvm-project/pull/96654
https://github.com/llvm/llvm-project/pull/93887
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/dzhidzhoev closed
https://github.com/llvm/llvm-project/pull/93887
___
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: Vladislav Dzhidzhoev (dzhidzhoev)
Changes
Makefile.rules uses HOST_OS and OS variables for determining host and target
OSes for API tests compilation.
When lldb's target is set to remote-linux, Makefile.rules script should be
executed wit
https://github.com/dzhidzhoev created
https://github.com/llvm/llvm-project/pull/96654
Makefile.rules uses HOST_OS and OS variables for determining host and target
OSes for API tests compilation.
When lldb's target is set to remote-linux, Makefile.rules script should be
executed with the targe
https://github.com/Michael137 edited
https://github.com/llvm/llvm-project/pull/96635
___
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: Michael Buch (Michael137)
Changes
Found this while skimming this code. Don't have a reproducible test case for
this but the nullptr check should clearly occur before we try to dereference
`location_sp`.
---
Full diff: https://github.com/l
https://github.com/Michael137 created
https://github.com/llvm/llvm-project/pull/96635
Found this while skimming this code. Don't have a reproducible test case for
this but the nullptr check should clearly occur before we try to dereference
`location_sp`.
>From 87edb6b9ba8b48e1bcddd2d73314cdb8
https://github.com/Michael137 ready_for_review
https://github.com/llvm/llvm-project/pull/96635
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/labath closed 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: Pavel Labath
Date: 2024-06-25T10:52:11+02:00
New Revision: 8395f9cecd34af8a79c96e661e46a80d0d471fb1
URL:
https://github.com/llvm/llvm-project/commit/8395f9cecd34af8a79c96e661e46a80d0d471fb1
DIFF:
https://github.com/llvm/llvm-project/commit/8395f9cecd34af8a79c96e661e46a80d0d471fb1.diff
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.
>
> Sure enough - I take any claim as a statement of intent/belief, not of
> something mathematically prov
labath wrote:
I've been trying to stay out of this, as I don't think I can be objective here,
but since I've been summoned, here's what I think. :)
For me, the worst possible outcome of this is an incomplete transition --
having a third (maybe fourth, since I sort of also count dwim-print)
ex
55 matches
Mail list logo
