https://github.com/jasonmolenda updated
https://github.com/llvm/llvm-project/pull/83663
>From c993c7cc7c1669ca7d06e52f1a1ff8dbefe9ebc9 Mon Sep 17 00:00:00 2001
From: Jason Molenda
Date: Thu, 29 Feb 2024 17:02:42 -0800
Subject: [PATCH 1/3] [lldb] Add SBProcess methods for get/set/use address
ma
adrian-prantl wrote:
So I reverted back to the state where I convert everything to int32_t. This way
I don't have to touch the UINT32_MAX sentinels in this patch, which should be
done separately and very carefully.
https://github.com/llvm/llvm-project/pull/83501
___
https://github.com/adrian-prantl updated
https://github.com/llvm/llvm-project/pull/83501
>From 44e21455e042a674f12f872be24ca9b7bb7d6dec Mon Sep 17 00:00:00 2001
From: Adrian Prantl
Date: Thu, 29 Feb 2024 15:06:28 -0800
Subject: [PATCH 1/3] Change the return type of
ValueObject::CalculateNumChi
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Alex Langford (bulbazord)
Changes
When Apple released its new linker, it had a subtle bug that caused LLDB's TLS
tests to fail. Unfortunately this means that TLS tests are not going to work on
machines that have affected versions of the li
https://github.com/bulbazord created
https://github.com/llvm/llvm-project/pull/83941
When Apple released its new linker, it had a subtle bug that caused LLDB's TLS
tests to fail. Unfortunately this means that TLS tests are not going to work on
machines that have affected versions of the linker
adrian-prantl wrote:
Folks I'm talking this all back. Changing the return type from a uint32_t to a
uint64_t is an all-or-nothing affair, because the UINT32_MAX sentinel value is
permeating a bunch of other APIs that I have not intention of changing right
now. For example, `GetIndexOfChildWith
https://github.com/rupprecht approved this pull request.
https://github.com/llvm/llvm-project/pull/83366
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/clayborg requested changes to this pull request.
So the only thing left to here is to stop using `UINT32_MAX` and switch to
using `UINT64_MAX` on internal APIs.
https://github.com/llvm/llvm-project/pull/83501
___
lldb-commits mailin
clayborg wrote:
> > Looking good. One question: do we want to switch to using a
> > `std::optional` instead of using a `uint64_t` with a default
> > value of UINT32_MAX? We should either use the optional or switch everything
> > except for the public API over to use `UINT64_MAX`
>
> The entir
rupprecht wrote:
> @rupprecht @oontvoo How do you feel about the current approach? The other
> alternative is to make this function a NOOP on all platforms but Darwin
> (where I want to actively use it). It's not currently load bearing (except
> the log, which is opt-in).
This approach LGTM.
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Greg Clayton (clayborg)
Changes
DWP files don't usually have a GNU build ID built into them. When searching for
a .dwp file, don't require a UUID to be in the .dwp file. The debug info search
information was checking for a UUID in the .dwp
https://github.com/clayborg created
https://github.com/llvm/llvm-project/pull/83935
DWP files don't usually have a GNU build ID built into them. When searching for
a .dwp file, don't require a UUID to be in the .dwp file. The debug info search
information was checking for a UUID in the .dwp fi
@@ -958,7 +958,7 @@ class ValueObject {
int32_t synthetic_index);
/// Should only be called by ValueObject::GetNumChildren().
- virtual size_t CalculateNumChildren(uint32_t max = UINT32_MAX) = 0;
+ virtual uint64_t CalculateNumChil
adrian-prantl wrote:
> Looking good. One question: do we want to switch to using a
> `std::optional` instead of using a `uint64_t` with a default value
> of UINT32_MAX? We should either use the optional or switch everything except
> for the public API over to use `UINT64_MAX`
The entire point
https://github.com/adrian-prantl updated
https://github.com/llvm/llvm-project/pull/83501
>From 4aeccd664633af57f12bfb7d0edada78c09a951e Mon Sep 17 00:00:00 2001
From: Adrian Prantl
Date: Mon, 4 Mar 2024 16:07:44 -0800
Subject: [PATCH 1/3] Change the return type of
ValueObject::CalculateNumChil
https://github.com/clayborg edited
https://github.com/llvm/llvm-project/pull/83501
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -958,7 +958,7 @@ class ValueObject {
int32_t synthetic_index);
/// Should only be called by ValueObject::GetNumChildren().
- virtual size_t CalculateNumChildren(uint32_t max = UINT32_MAX) = 0;
+ virtual uint64_t CalculateNumChil
https://github.com/clayborg commented:
Looking good. One question: do we want to switch to using a
`std::optional` instead of using a `uint64_t` with a default value of
UINT32_MAX? We should either use the optional or switch everything except for
the public API over to use `UINT64_MAX`
https:
https://github.com/adrian-prantl updated
https://github.com/llvm/llvm-project/pull/83501
>From 4aeccd664633af57f12bfb7d0edada78c09a951e Mon Sep 17 00:00:00 2001
From: Adrian Prantl
Date: Mon, 4 Mar 2024 16:07:44 -0800
Subject: [PATCH 1/2] Change the return type of
ValueObject::CalculateNumChil
jimingham wrote:
We don't do the latter anywhere. This is really equivalent to the:
target.breakpoints-use-platform-avoid-list setting, which is also about "stop
at places most normal human beings don't want to stop". In the extant setting
it's about whole libraries, the new setting would be
https://github.com/felipepiovezan closed
https://github.com/llvm/llvm-project/pull/83925
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Author: Felipe de Azevedo Piovezan
Date: 2024-03-04T15:45:43-08:00
New Revision: 488ac3d5ef31237e38de6da627a619459e0ca19a
URL:
https://github.com/llvm/llvm-project/commit/488ac3d5ef31237e38de6da627a619459e0ca19a
DIFF:
https://github.com/llvm/llvm-project/commit/488ac3d5ef31237e38de6da627a619459
felipepiovezan wrote:
> Also, are these 100% uninteresting line table entries? At present, there's no
> way to get lldb to not filter them out, so they either really need to be
> totally uninteresting, or we need a setting to turn them back on again.
They should be 100% uninteresting, but I ag
https://github.com/medismailben closed
https://github.com/llvm/llvm-project/pull/83861
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Author: Med Ismail Bennani
Date: 2024-03-04T15:44:44-08:00
New Revision: 5000e4c2527ae53bf7c1a609f739a97cdc522bbe
URL:
https://github.com/llvm/llvm-project/commit/5000e4c2527ae53bf7c1a609f739a97cdc522bbe
DIFF:
https://github.com/llvm/llvm-project/commit/5000e4c2527ae53bf7c1a609f739a97cdc522bbe.
https://github.com/JDevlieghere approved this pull request.
LGTM!
https://github.com/llvm/llvm-project/pull/83861
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/medismailben updated
https://github.com/llvm/llvm-project/pull/83861
>From 5cc9da6d222ff39f2939cdb725477e94f8fb24f8 Mon Sep 17 00:00:00 2001
From: Med Ismail Bennani
Date: Mon, 4 Mar 2024 15:41:45 -0800
Subject: [PATCH] [lldb/crashlog] Fix breaking changes in textual report f
https://github.com/JDevlieghere approved this pull request.
https://github.com/llvm/llvm-project/pull/83925
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
felipepiovezan wrote:
@JDevlieghere I believe you were the last one to touch this test, so I'll let
you approve this :D
https://github.com/llvm/llvm-project/pull/83925
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Felipe de Azevedo Piovezan (felipepiovezan)
Changes
According to the git log (d9442afba1bd6), this test has never been
enabled/disabled, it was checked in without being called anywhere. But it
passes and it is useful, so this commit enable
https://github.com/felipepiovezan created
https://github.com/llvm/llvm-project/pull/83925
According to the git log (d9442afba1bd6), this test has never been
enabled/disabled, it was checked in without being called anywhere. But it
passes and it is useful, so this commit enables it.
>From 009f
https://github.com/MaskRay approved this pull request.
https://github.com/llvm/llvm-project/pull/83702
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
joker-eph wrote:
> One patch ThreadPool->DefaultThreadPool (people get a build error about
> ThreadPool not being the name of anything, find this patch as the root cause,
> and rename all their ThreadPool->DefaultThreadPool)
Gotcha, thanks for elaborating, somehow my brain was slow on a Monday
adrian-prantl wrote:
My main point was to unify it, but I have no problem with going for `uint64_t`
instead. I'll update the patch.
https://github.com/llvm/llvm-project/pull/83501
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists
jimingham wrote:
LGTM except you should have a little bit of doc describing what "interesting"
means. On the face of it, this seems a little silly. Why would the compiler
emit "uninteresting" line table entries? Your example motivation the PR makes
that clear, that or something like in the
bulbazord wrote:
> I would almost vote to change everything to `uint64_t` except for the public
> API since we can't change the API without breaking. Though I winder if we can
> actually change this one:
>
> ```
> uint64_t SBValue::GetNumChildren();
> ```
>
> Since the return value isn't mang
https://github.com/clayborg approved this pull request.
https://github.com/llvm/llvm-project/pull/82799
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
clayborg wrote:
I would vote for `uint64_t` over `size_t` as `size_t` is 32 bits on 32 bit
operating systems and we might be cross debugging to 64 bit systems that need
`uint64_t`
https://github.com/llvm/llvm-project/pull/83501
___
lldb-commits maili
pogo59 wrote:
> separating them might be marginally better for downstrteamers.
Hear, hear.
https://github.com/llvm/llvm-project/pull/83702
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-c
dwblaikie wrote:
> @dwblaikie : how would you split it? I didn't quite get the two renamings you
> have in mind?
One patch `ThreadPool->DefaultThreadPool` (people get a build error about
`ThreadPool` not being the name of anything, find this patch as the root cause,
and rename all their Threa
joker-eph wrote:
@dwblaikie : how would you split it? I didn't quite get the two renamings you
have in mind?
https://github.com/llvm/llvm-project/pull/83702
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailm
https://github.com/clayborg commented:
I would almost vote to change everything to `uint64_t` except for the public
API since we can't change the API without breaking. Though I winder if we can
actually change this one:
```
uint64_t SBValue::GetNumChildren();
```
Since the return value isn't ma
dwblaikie wrote:
I don't have really firm feelings/justification for this, but I'd have guessed
that doing this as two separate (separated by a few days, maybe a week)
renamings would be better for downstream consumers - they'd get a clear break
without any ambiguity/name reuse.
No strong fee
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Felipe de Azevedo Piovezan (felipepiovezan)
Changes
Some languages may create artificial functions that have no real user code,
even though there is line table information for them. One such case is with
coroutine code that receives the Co
https://github.com/felipepiovezan created
https://github.com/llvm/llvm-project/pull/83908
Some languages may create artificial functions that have no real user code,
even though there is line table information for them. One such case is with
coroutine code that receives the CoroSplitter transf
https://github.com/JDevlieghere closed
https://github.com/llvm/llvm-project/pull/83871
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Author: Alexander M
Date: 2024-03-04T11:54:24-08:00
New Revision: 79e8f29ab06560d159389d940c35c563e0c8640e
URL:
https://github.com/llvm/llvm-project/commit/79e8f29ab06560d159389d940c35c563e0c8640e
DIFF:
https://github.com/llvm/llvm-project/commit/79e8f29ab06560d159389d940c35c563e0c8640e.diff
L
https://github.com/medismailben closed
https://github.com/llvm/llvm-project/pull/83895
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Author: Med Ismail Bennani
Date: 2024-03-04T11:42:04-08:00
New Revision: f32c6b28b84130dc77e0e69d6d3b692aec933280
URL:
https://github.com/llvm/llvm-project/commit/f32c6b28b84130dc77e0e69d6d3b692aec933280
DIFF:
https://github.com/llvm/llvm-project/commit/f32c6b28b84130dc77e0e69d6d3b692aec933280.
amordo wrote:
@JDevlieghere I have no write access, looking for help:)
https://github.com/llvm/llvm-project/pull/83871
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/JDevlieghere approved this pull request.
https://github.com/llvm/llvm-project/pull/83895
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/medismailben updated
https://github.com/llvm/llvm-project/pull/83895
>From 0b71b6aafe6a11875ebdb77ecafd63d1ad4556f4 Mon Sep 17 00:00:00 2001
From: Med Ismail Bennani
Date: Mon, 4 Mar 2024 11:25:07 -0800
Subject: [PATCH] [lldb/Test] Fix oversight in ProcessEventDataTest::SetUp
https://github.com/medismailben created
https://github.com/llvm/llvm-project/pull/83895
This patch addresses an oversight in `ProcessEventDataTest::SetUp` unittest to
ensure the Debugger is initialized properly.
>From 1ed521f9de503fd48834a250fb2f071c2d86b1c9 Mon Sep 17 00:00:00 2001
From: Med
Author: Jordan Rupprecht
Date: 2024-03-04T11:21:47-08:00
New Revision: 503075e4d4a9c1b3754b21ee9ec41f176e54fd83
URL:
https://github.com/llvm/llvm-project/commit/503075e4d4a9c1b3754b21ee9ec41f176e54fd83
DIFF:
https://github.com/llvm/llvm-project/commit/503075e4d4a9c1b3754b21ee9ec41f176e54fd83.di
JDevlieghere wrote:
@amordo I don't know if you have commit access. Let me you need someone to
press the merge button for you.
https://github.com/llvm/llvm-project/pull/83871
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm
https://github.com/JDevlieghere approved this pull request.
Apologies for the delay. LGTM!
https://github.com/llvm/llvm-project/pull/78977
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-co
https://github.com/JDevlieghere closed
https://github.com/llvm/llvm-project/pull/83889
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Author: Jonas Devlieghere
Date: 2024-03-04T10:44:17-08:00
New Revision: 1da5db97cbf3451da05788b1d35b8a107a7f6a69
URL:
https://github.com/llvm/llvm-project/commit/1da5db97cbf3451da05788b1d35b8a107a7f6a69
DIFF:
https://github.com/llvm/llvm-project/commit/1da5db97cbf3451da05788b1d35b8a107a7f6a69.d
https://github.com/jasonmolenda approved this pull request.
https://github.com/llvm/llvm-project/pull/83889
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/JDevlieghere approved this pull request.
LGTM!
https://github.com/llvm/llvm-project/pull/83871
___
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: Jonas Devlieghere (JDevlieghere)
Changes
Use sort-ordering for indexes when sorting by size. This addresses Jason's post
commit review feedback.
---
Full diff: https://github.com/llvm/llvm-project/pull/83889.diff
2 Files Affected:
- (mo
@@ -138,6 +134,21 @@ void Symtab::Dump(Stream *s, Target *target, SortOrder
sort_order,
}
} break;
+case eSortOrderBySize: {
+ s->PutCString(" (sorted by size):\n");
+ DumpSymbolHeader(s);
+
+ std::multimap> size_map;
+ for (const Symbol &sym
https://github.com/JDevlieghere created
https://github.com/llvm/llvm-project/pull/83889
Use sort-ordering for indexes when sorting by size. This addresses Jason's post
commit review feedback.
>From 13b644f483a349bb853d917e0771e811a1bf9be2 Mon Sep 17 00:00:00 2001
From: Jonas Devlieghere
Date:
jasonmolenda wrote:
> > is about how TestAddressMasks.py assumes all Fix*Address implementations
> > will handle a low and high memory address mask. The test currently assumes
> > they do
>
> I'm not sure it makes much difference unless handling low/high produces a
> large amount of boilerpla
@@ -138,6 +134,21 @@ void Symtab::Dump(Stream *s, Target *target, SortOrder
sort_order,
}
} break;
+case eSortOrderBySize: {
+ s->PutCString(" (sorted by size):\n");
+ DumpSymbolHeader(s);
+
+ std::multimap> size_map;
+ for (const Symbol &sym
rupprecht wrote:
> FYI @labath as the x86 bot owner.
I checked w/ them that
[lldb-x86_64-debian](https://lab.llvm.org/buildbot/#/builders/68) has
python3-pexpect (specifically 4.8) installed.
> > It should perhaps unset the variable first, I'll see if I can implement
> > that.
>
> [ec95379]
https://github.com/Michael137 closed
https://github.com/llvm/llvm-project/pull/83582
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Author: Michael Buch
Date: 2024-03-04T17:17:13Z
New Revision: 252f3c98db1383ee0e1f25020d488ffb7b4ac392
URL:
https://github.com/llvm/llvm-project/commit/252f3c98db1383ee0e1f25020d488ffb7b4ac392
DIFF:
https://github.com/llvm/llvm-project/commit/252f3c98db1383ee0e1f25020d488ffb7b4ac392.diff
LOG:
@@ -0,0 +1,10 @@
+include Makefile.rules
+
+OBJECTS += main.o
+
+$(EXE): $(BUILDDIR)/main.o
+
+$(BUILDDIR)/main.o: main.cpp
+ $(CC) -cc1 -emit-pch -x c++-header -fmodule-format=obj -fmodules -O0
-dwarf-ext-refs -debug-info-kind=standalone $(SRCDIR)/base-pch.h -o
base-pch.h
https://github.com/adrian-prantl approved this pull request.
https://github.com/llvm/llvm-project/pull/83582
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/adrian-prantl edited
https://github.com/llvm/llvm-project/pull/83582
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
JDevlieghere wrote:
Can you add/modify a test?
https://github.com/llvm/llvm-project/pull/83861
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
lattner wrote:
Nice work Mehdi!
https://github.com/llvm/llvm-project/pull/82094
___
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: Alexander M. (amordo)
Changes
Add `liblldb` dependency and use correct extension for compiled Lua module.
Replace 'Python' with 'Lua' in install path name.
Fixes #55075.
---
Full diff: https://github.com/llvm/llvm-project/pull/83871.diff
https://github.com/amordo created
https://github.com/llvm/llvm-project/pull/83871
Add `liblldb` dependency and use correct extension for compiled Lua module.
Replace 'Python' with 'Lua' in install path name.
Fixes #55075.
>From 678ea6f6e6234b72c93f2c5e5323f76cdf252377 Mon Sep 17 00:00:00 2001
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Med Ismail Bennani (medismailben)
Changes
This patch should address some register parsing issue in the legacy report
format.
rdar://107210149
---
Full diff: https://github.com/llvm/llvm-project/pull/83861.diff
1 Files Affected:
- (modi
https://github.com/medismailben created
https://github.com/llvm/llvm-project/pull/83861
This patch should address some register parsing issue in the legacy report
format.
rdar://107210149
>From b3ad739752a6e07eeeda47055d17a12fc960adcb Mon Sep 17 00:00:00 2001
From: Med Ismail Bennani
Date: S
DavidSpickett wrote:
> is about how TestAddressMasks.py assumes all Fix*Address implementations
> will handle a low and high memory address mask. The test currently assumes
> they do
I'm not sure it makes much difference unless handling low/high produces a large
amount of boilerplate in ever
78 matches
Mail list logo
