https://github.com/labath approved this pull request.
https://github.com/llvm/llvm-project/pull/111483
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -111,6 +111,8 @@ def do_test(self, one_target, one_debugger):
else:
if one_target:
new_debugger = lldb.SBDebugger().Create()
+if lldb.selected_platform is not None:
+new_debugger.SetSelectedPlatform(lldb
jasonmolenda wrote:
Let me just take a peek at some Darwin binaries with this codegen & their
debuginfo, and then i'll approve unless there's something I've misunderstood
about what we're looking at. It really makes me think that we are going to
need discontiguous ranges in the unwind plans t
jasonmolenda wrote:
This is interesting, sorry the uncached unwindplans made it harder to debug.
I've seen cold function outlining in our libraries but I've never looked at the
generated DWARF - does the function die have a location list with the main
function body and the .cold.1 function b
jasonmolenda wrote:
I built the swiftlang `rebranch` sources clean, with the parallel patch, with
the parallel plus preload patch. I ran them against the same Slack binary with
934 binary images, 10 of them outside the shared cache. I built them something
like
```
swift/utils/build-script --
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Igor Kudrin (igorkudrin)
Changes
`SBDebugger().Create()` returns a debugger with only the host platform in its
platform list. If the test suite is running for a remote platform, it should be
explicitly added and selected in the new debugge
https://github.com/igorkudrin created
https://github.com/llvm/llvm-project/pull/111483
`SBDebugger().Create()` returns a debugger with only the host platform in its
platform list. If the test suite is running for a remote platform, it should be
explicitly added and selected in the new debugger
https://github.com/AbdAlRahmanGad updated
https://github.com/llvm/llvm-project/pull/110718
>From b4afb0b69bc07b5df72e2db29af4bc09bcafa526 Mon Sep 17 00:00:00 2001
From: AbdAlRahman Gad
Date: Tue, 1 Oct 2024 21:15:13 +0300
Subject: [PATCH 1/5] [lldb] Change
SymbolContext::GetAddressRangeFromHer
github-actions[bot] wrote:
@Surinrasu Congratulations on having your first Pull Request (PR) merged into
the LLVM Project!
Your changes will be combined with recent changes from other authors, then
tested by our [build bots](https://lab.llvm.org/buildbot/). If there is a
problem with a buil
https://github.com/JDevlieghere closed
https://github.com/llvm/llvm-project/pull/111326
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Author: 苏灵素@夏日限定
Date: 2024-10-07T21:29:39-07:00
New Revision: 646aa817d2944f78638ca5fc1d037bff5e1fd490
URL:
https://github.com/llvm/llvm-project/commit/646aa817d2944f78638ca5fc1d037bff5e1fd490
DIFF:
https://github.com/llvm/llvm-project/commit/646aa817d2944f78638ca5fc1d037bff5e1fd490.diff
LOG:
jasonmolenda wrote:
It is a bit interesting that the user and system time are so much higher --
looks like around 40% higher? -- than the single-threaded approach, I wonder if
that's thread creation/teardown overhead, or if it's costlier to acquire locks
and it's adding up. Wallclock is the r
jasonmolenda wrote:
I know your benchmarking numbers are against the `main` swiftlang branch which
is using stable/20230725 - it's a bit older than llvm-project main as you'd
guess from the date. They're bringing up the `rebranch` branch right now to
become `main` at some point (I haven't fol
https://github.com/AbdAlRahmanGad updated
https://github.com/llvm/llvm-project/pull/110718
>From b4afb0b69bc07b5df72e2db29af4bc09bcafa526 Mon Sep 17 00:00:00 2001
From: AbdAlRahman Gad
Date: Tue, 1 Oct 2024 21:15:13 +0300
Subject: [PATCH 1/4] [lldb] Change
SymbolContext::GetAddressRangeFromHer
DmT021 wrote:
Anyway, my main goal is iOS apps running in the simulator. And for them, the
speed-up is much more noticeable (at least for big apps). Let me know if you'd
like me to measure something else.
https://github.com/llvm/llvm-project/pull/110439
adrian-prantl wrote:
Thanks, this looks nice!
https://github.com/llvm/llvm-project/pull/110718
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -489,11 +489,12 @@ class CommandObjectThreadStepWithTypeAndScope : public
CommandObjectParsed {
AddressRange range;
SymbolContext sc = frame->GetSymbolContext(eSymbolContextEverything);
if (m_options.m_end_line != LLDB_INVALID_LINE_NUMBER) {
-
DmT021 wrote:
Nice. Also there's no significant difference between `build.release` and
`release.parallel-with-preload` with sequential load which is good.
I wonder why your parallel runs are slightly less performant than mine relative
to the sequential ones. I mean it's almost certainly the con
jasonmolenda wrote:
So yes, I'm seeing a 30% improvement with the multithreaded creation of
Modules, for a macOS app mostly in the shared cache.
https://github.com/llvm/llvm-project/pull/110439
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
jasonmolenda wrote:
For completeness sakes, here's what I see for parallel+preload PR 110646 with
llvm-project main (no swift demangling) attaching to Slack (nearly all
libraries in the shared cache)
```
% time build.release.parallel-with-preload//bin/lldb -x -b -o 'pro att -n
Slack' -o 'det
jasonmolenda wrote:
Ah wait, I see where the difference is coming in -- it's my own fault. I
misread tcsh's time output and only looked at USER seconds. Looking at the
wallclock times, we're 50% faster with the multithreading enabled for this PR's
change. My apologies!
https://github.com/l
jasonmolenda wrote:
Hmmm, interesting. I built my optimized builds with
```
cmake ../llvm -G Ninja -DLLDB_ENABLE_SWIFT_SUPPORT=0
-DPython3_EXECUTABLE=/usr/bin/python3 -DCMAKE_BUILD_TYPE=RelWithDebInfo
-DLLVM_ENABLE_ASSERTIONS=1 -DLLVM_ENABLE_PROJECTS='llvm;lldb;clang'
'-DLLVM_ENABLE_RUNTIMES=
igorkudrin wrote:
> I don't see any relevant changes on those files, so I don't know the where
> `openNativeFileInternal()` comes into the picture.
`getFileAux()` calls `openNativeFileForRead()` first and then passes the file
descriptor to `getOpenFileImpl()`. `openNativeFileForRead()` eventu
DmT021 wrote:
@jasonmolenda I tried to reproduce your results but got drastically different
numbers for parallel runs. Here's the setup:
- Using this (the main) repository of llvm-project.
- `cmake -G Ninja -DLLVM_ENABLE_PROJECTS="clang;lldb;lld"
-DCMAKE_BUILD_TYPE=RelWithDebInfo -DLLVM_ENABLE_
emrekultursay wrote:
> it failed in this case because the source file is opened with the
> `FILE_SHARE_DELETE` share mode, which allows the file to be removed, see
> `llvm::sys::fs::openNativeFileInternal()` in
> `llvm/lib/Support/Windows/Path.inc`.
Was there an LLDB change about how it open
https://github.com/clayborg approved this pull request.
https://github.com/llvm/llvm-project/pull/99736
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -75,8 +75,7 @@ Status
MinidumpFileBuilder::AddHeaderAndCalculateDirectories() {
StopInfoSP stop_info_sp = thread_sp->GetStopInfo();
if (stop_info_sp) {
const StopReason &stop_reason = stop_info_sp->GetStopReason();
- if (stop_reason == StopReason::eStopRe
@@ -685,50 +684,43 @@ Status MinidumpFileBuilder::AddExceptions() {
Status error;
for (const ThreadSP &thread_sp : thread_list) {
StopInfoSP stop_info_sp = thread_sp->GetStopInfo();
-bool add_exception = false;
-if (stop_info_sp) {
- switch (stop_info_sp->G
@@ -273,8 +273,14 @@ void ProcessMinidump::RefreshStateAfterStop() {
// No stop.
return;
}
-
- stop_info = StopInfo::CreateStopReasonWithSignal(*stop_thread, signo);
+ const char *description = nullptr;
+ if (exception_stream.ExceptionRecord
https://github.com/clayborg requested changes to this pull request.
https://github.com/llvm/llvm-project/pull/108448
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
DmT021 wrote:
@augusto2112 Thank you!
https://github.com/llvm/llvm-project/pull/102835
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
github-actions[bot] wrote:
@DmT021 Congratulations on having your first Pull Request (PR) merged into the
LLVM Project!
Your changes will be combined with recent changes from other authors, then
tested by our [build bots](https://lab.llvm.org/buildbot/). If there is a
problem with a build,
https://github.com/augusto2112 closed
https://github.com/llvm/llvm-project/pull/102835
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Author: Dmitrii Galimzianov
Date: 2024-10-07T13:45:27-07:00
New Revision: d2457e6d8f62a12b3b74791cfd3f5808168c8a71
URL:
https://github.com/llvm/llvm-project/commit/d2457e6d8f62a12b3b74791cfd3f5808168c8a71
DIFF:
https://github.com/llvm/llvm-project/commit/d2457e6d8f62a12b3b74791cfd3f5808168c8a71
DmT021 wrote:
@Michael137 I don't have merge rights, can you merge this pls?
https://github.com/llvm/llvm-project/pull/102835
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/Jlalond updated
https://github.com/llvm/llvm-project/pull/109477
>From 0beb848dcab2fb84d79dca126efaca3c5e2cffe7 Mon Sep 17 00:00:00 2001
From: Jacob Lalonde
Date: Mon, 16 Sep 2024 13:02:59 -0700
Subject: [PATCH 01/12] Add Process code to get the fs_base region and the
.tdata
https://github.com/Jlalond updated
https://github.com/llvm/llvm-project/pull/108448
>From 7bdbce7ef2f60e819dea296ff8da832c1acbaef6 Mon Sep 17 00:00:00 2001
From: Jacob Lalonde
Date: Thu, 12 Sep 2024 13:10:58 -0700
Subject: [PATCH 1/9] Create set for the stop reasons we collect, and add
breakpo
igorkudrin wrote:
> As I understand it, Android Studio was setting `use-source-cache:=false` so
> that users can continue to edit files on windows while lldb has them open.
>
> Judging by this patch, that may no longer be necessary. Or does that only
> apply for certain situations (certain win
jimingham wrote:
I don't think there's a lot of reason to support registering lists of lldb
commands for the event, just having a python callback should be enough. I
think it's better to just do a scripted callback, and then have some command
that lets you add callbacks by module & class name
igorkudrin wrote:
> Looks good, I guess. Is that constructor even necessary, given that it just
> forwards the argument to the base class, and we already have the forwarding
> `using` declaration?
The constructor looks redundant at the moment, perhaps it is just a legacy from
the early stages
@@ -145,6 +164,7 @@ struct ThreadData {
int signo = 0;
int code = 0;
int prstatus_sig = 0;
+ std::string description;
Jlalond wrote:
I'm going to lightly push back on this. ProcessElfCore currently depends a lot
on threaddata, not just for populating t
@@ -76,14 +76,33 @@ static_assert(sizeof(ELFLinuxPrStatus) == 112,
"sizeof ELFLinuxPrStatus is not correct!");
struct ELFLinuxSigInfo {
- int32_t si_signo;
- int32_t si_code;
+ int32_t si_signo; // Order matters for the first 3.
int32_t si_errno;
+ int32_t
https://github.com/Jlalond updated
https://github.com/llvm/llvm-project/pull/108448
>From 7bdbce7ef2f60e819dea296ff8da832c1acbaef6 Mon Sep 17 00:00:00 2001
From: Jacob Lalonde
Date: Thu, 12 Sep 2024 13:10:58 -0700
Subject: [PATCH 1/8] Create set for the stop reasons we collect, and add
breakpo
https://github.com/dzhidzhoev closed
https://github.com/llvm/llvm-project/pull/95986
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Author: Vladislav Dzhidzhoev
Date: 2024-10-07T20:31:33+02:00
New Revision: 32e90bbe579d39356ebd269158b1b5eef82761d4
URL:
https://github.com/llvm/llvm-project/commit/32e90bbe579d39356ebd269158b1b5eef82761d4
DIFF:
https://github.com/llvm/llvm-project/commit/32e90bbe579d39356ebd269158b1b5eef82761d
dzhidzhoev wrote:
> LGTM.
>
> Maybe @labath would like to take a last look at it before it lands.
I assume there are no more comments, so I'll merge it. I'm open for further
corrections.
https://github.com/llvm/llvm-project/pull/95986
___
lldb-commi
vogelsgesang wrote:
see https://llvm.org/docs/DeveloperPolicy.html#obtaining-commit-access for
instructions
https://github.com/llvm/llvm-project/pull/106919
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailm
https://github.com/Jlalond approved this pull request.
Some Minor comments, but I think Pavel pointed out everything important. LGTM
https://github.com/llvm/llvm-project/pull/108907
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://list
https://github.com/Jlalond edited
https://github.com/llvm/llvm-project/pull/108907
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -374,6 +375,21 @@ void DebugNamesDWARFIndex::GetFullyQualifiedType(
m_fallback.GetFullyQualifiedType(context, callback);
}
+bool DebugNamesDWARFIndex::SameAsEntryContext(
+const CompilerContext &query_context,
+const DebugNames::Entry &entry) const {
+ // TODO: c
@@ -444,6 +499,72 @@ void DebugNamesDWARFIndex::GetNamespaces(
m_fallback.GetNamespaces(name, callback);
}
+llvm::SmallVector
+DebugNamesDWARFIndex::GetTypeQueryParentContexts(TypeQuery &query) {
+ std::vector &query_decl_context =
+ query.GetContextRef();
+ llvm::Sma
clayborg wrote:
I have wanted to be able to hook into target creation to be able to setup
targets when they get created. It would be also nice to get an event when a
process is not longer being debugged due to process exit or detach.
https://github.com/llvm/llvm-project/pull/111206
___
https://github.com/Jlalond updated
https://github.com/llvm/llvm-project/pull/109477
>From f432d21587c32ca5e6dc96fc77fbc53a3ae5eeb8 Mon Sep 17 00:00:00 2001
From: Jacob Lalonde
Date: Mon, 16 Sep 2024 13:02:59 -0700
Subject: [PATCH 01/12] Add Process code to get the fs_base region and the
.tdata
clayborg wrote:
> @jimingham , @clayborg, do you guys prefer `target stop-hook` style approach
> or `SBNotificationCallback` style python API callback?
>
> @clayborg, for `SBNotificationCallback`, does `lldb::SBExecutionContext` wrap
> the process, target or debugger object that is creating/de
@@ -145,6 +164,7 @@ struct ThreadData {
int signo = 0;
int code = 0;
int prstatus_sig = 0;
+ std::string description;
clayborg wrote:
We might be able to remove all of these and just replace these with a
`lldb::StopInfoSP` and always either create a `l
@@ -76,14 +76,33 @@ static_assert(sizeof(ELFLinuxPrStatus) == 112,
"sizeof ELFLinuxPrStatus is not correct!");
struct ELFLinuxSigInfo {
- int32_t si_signo;
- int32_t si_code;
+ int32_t si_signo; // Order matters for the first 3.
int32_t si_errno;
+ int32_t
@@ -183,6 +203,7 @@ class ThreadElfCore : public lldb_private::Thread {
int m_signo;
int m_code;
+ std::string m_sig_description;
clayborg wrote:
See `lldb::StopInfoSP` comment above. We seem to be duplicating info from the
`siginto_t` struct in both
@@ -76,14 +76,33 @@ static_assert(sizeof(ELFLinuxPrStatus) == 112,
"sizeof ELFLinuxPrStatus is not correct!");
struct ELFLinuxSigInfo {
- int32_t si_signo;
- int32_t si_code;
+ int32_t si_signo; // Order matters for the first 3.
int32_t si_errno;
+ int32_t
@@ -76,14 +76,33 @@ static_assert(sizeof(ELFLinuxPrStatus) == 112,
"sizeof ELFLinuxPrStatus is not correct!");
struct ELFLinuxSigInfo {
- int32_t si_signo;
- int32_t si_code;
+ int32_t si_signo; // Order matters for the first 3.
int32_t si_errno;
+ int32_t
@@ -76,14 +76,33 @@ static_assert(sizeof(ELFLinuxPrStatus) == 112,
"sizeof ELFLinuxPrStatus is not correct!");
struct ELFLinuxSigInfo {
- int32_t si_signo;
- int32_t si_code;
+ int32_t si_signo; // Order matters for the first 3.
int32_t si_errno;
+ int32_t
jurahul wrote:
@JDevlieghere or @dwblaikie one last ping to comment if consistency of file
names is a strong enough motivation. If not, I will drop this.
https://github.com/llvm/llvm-project/pull/110692
___
lldb-commits mailing list
lldb-commits@lists
jeffreytan81 wrote:
@jimingham , @clayborg, do you guys prefer `target stop-hook` style approach or
`SBNotificationCallback` style python API callback?
@clayborg, for `SBNotificationCallback`, does `lldb::SBExecutionContext` wrap
the process, target or debugger object that is creating/destro
jeffreytan81 wrote:
> Also, if you are going to hook creation, you should also hook destruction,
> shouldn't you? Whatever accounting you are doing for a debugger's once it
> exists might need to be torn down when that debugger goes away.
Right, `SBDebugger::AddDestroyCallback()` already exist
https://github.com/Jlalond updated
https://github.com/llvm/llvm-project/pull/110065
>From 57e287fbd426306d2ebc3a39d8ed8e8b7309a79c Mon Sep 17 00:00:00 2001
From: Jacob Lalonde
Date: Tue, 24 Sep 2024 17:42:49 -0700
Subject: [PATCH 01/11] Add the addr info when appropriate for NIX' crash
signals
@@ -3583,10 +3583,12 @@ class CommandObjectTargetModulesShowUnwind : public
CommandObjectParsed {
addr_t start_addr = range.GetBaseAddress().GetLoadAddress(target);
if (abi)
start_addr = abi->FixCodeAddress(start_addr);
+ range.GetBaseAddress().SetLoad
abhina-sree wrote:
> https://github.com/llvm/llvm-project/blob/main/clang/lib/Lex/PPDirectives.cpp#L3964-L3990
Yes I think we still require specifying the Text/Binary parameter based on the
context of where it is called. I will look into adding the new virtual
functions as an alternative solu
https://github.com/clayborg commented:
As Jim was saying, we might be able to make something a bit more useful so that
we can easily extend for other notifications of a debug session lifetime. Maybe
instead of:
```
typedef void (*SBDebuggerCreateCallback)(lldb::SBDebugger &debugger, void
*bato
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Pavel Labath (labath)
Changes
Currently, our unwinder assumes that the functions are continuous (or at least,
that there are no functions which are "in the middle" of other functions).
Neither of these assumptions is true for functions opt
https://github.com/labath created
https://github.com/llvm/llvm-project/pull/111409
Currently, our unwinder assumes that the functions are continuous (or at least,
that there are no functions which are "in the middle" of other functions).
Neither of these assumptions is true for functions optim
https://github.com/Jlalond updated
https://github.com/llvm/llvm-project/pull/110065
>From 57e287fbd426306d2ebc3a39d8ed8e8b7309a79c Mon Sep 17 00:00:00 2001
From: Jacob Lalonde
Date: Tue, 24 Sep 2024 17:42:49 -0700
Subject: [PATCH 01/10] Add the addr info when appropriate for NIX' crash
signals
DmT021 wrote:
@jasonmolenda If you still have a build with the patch can you please compare
the unmodified version with the patched one with `enable-parallel-image-load`
disabled? There shouldn't be a noticeable difference. If you don't it's ok, I
haven't had time to inspect it yet but I'll tr
https://github.com/bulbazord approved this pull request.
https://github.com/llvm/llvm-project/pull/111326
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
bulbazord wrote:
Love to see this kind of work done.
FWIW I worked on improving the performance of `ObjectFileMachO::ParseSymtab` in
https://github.com/llvm/llvm-project/pull/106791.
That change to reverted and I haven't had the time to figure out what happened
yet though...
https://github.com
jimingham wrote:
Also, if you are going to hook creation, you should also hook destruction,
shouldn't you? Whatever accounting you are doing for a debugger's once it
exists might need to be torn down when that debugger goes away.
https://github.com/llvm/llvm-project/pull/111206
__
jimingham wrote:
I'm of two minds about this. OTOH, it is certainly useful to be able to
observe Debugger creation. OTOH, it would be equally useful to be able to
observe Target creation and Process creation and probably other "debugger
lifecycle" events.
One of the tasks I've not had time
jasonmolenda wrote:
> > Built RelWithDebInfo, unmodified lldb took 4.5 seconds. Parallel took 6.6
> > seconds. Parallel with preload took 6.7 seconds.
> > Built Debug, unmodified lldb took 27.6 seconds. Parallel took 35.5 seconds.
> > Parallel plus preload took 35.6 seconds.
>
> Oh wow. 4.5 s
https://github.com/Jlalond closed
https://github.com/llvm/llvm-project/pull/110885
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Author: Jacob Lalonde
Date: 2024-10-07T09:45:56-07:00
New Revision: 5d372ea6a1e438b8e9583391d40cfcf34210d4f7
URL:
https://github.com/llvm/llvm-project/commit/5d372ea6a1e438b8e9583391d40cfcf34210d4f7
DIFF:
https://github.com/llvm/llvm-project/commit/5d372ea6a1e438b8e9583391d40cfcf34210d4f7.diff
walter-erquinigo wrote:
@Da-Viper , you should request commit access!
https://github.com/llvm/llvm-project/pull/106919
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/walter-erquinigo closed
https://github.com/llvm/llvm-project/pull/106919
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Author: Da-Viper
Date: 2024-10-07T12:38:36-04:00
New Revision: d4c17891126a79ae49237a7de0f9948aeedcd177
URL:
https://github.com/llvm/llvm-project/commit/d4c17891126a79ae49237a7de0f9948aeedcd177
DIFF:
https://github.com/llvm/llvm-project/commit/d4c17891126a79ae49237a7de0f9948aeedcd177.diff
LOG:
https://github.com/Michael137 edited
https://github.com/llvm/llvm-project/pull/110856
___
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/110856
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/Michael137 updated
https://github.com/llvm/llvm-project/pull/110856
>From 344819ad0ad1949aaf0469bfba4450674d8ec8cf Mon Sep 17 00:00:00 2001
From: Michael Buch
Date: Wed, 2 Oct 2024 15:44:28 +0100
Subject: [PATCH 1/8] [lldb][CMake] Add single target that runs libc++ tests
---
Author: Michael Buch
Date: 2024-10-07T17:38:14+02:00
New Revision: 5e7cc374225e1704d0694da05e02f327cc0cf024
URL:
https://github.com/llvm/llvm-project/commit/5e7cc374225e1704d0694da05e02f327cc0cf024
DIFF:
https://github.com/llvm/llvm-project/commit/5e7cc374225e1704d0694da05e02f327cc0cf024.diff
https://github.com/dzhidzhoev closed
https://github.com/llvm/llvm-project/pull/99
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Author: Vladislav Dzhidzhoev
Date: 2024-10-07T17:37:44+02:00
New Revision: 0e8a10b099a230f5193f228467538e6443afa398
URL:
https://github.com/llvm/llvm-project/commit/0e8a10b099a230f5193f228467538e6443afa398
DIFF:
https://github.com/llvm/llvm-project/commit/0e8a10b099a230f5193f228467538e6443afa39
Author: Pavel Labath
Date: 2024-10-07T16:53:26+02:00
New Revision: 0e2970f0ad723a3b4e56d18858f4fd215415002f
URL:
https://github.com/llvm/llvm-project/commit/0e2970f0ad723a3b4e56d18858f4fd215415002f
DIFF:
https://github.com/llvm/llvm-project/commit/0e2970f0ad723a3b4e56d18858f4fd215415002f.diff
https://github.com/labath closed
https://github.com/llvm/llvm-project/pull/111353
___
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/110837
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Author: Vladislav Dzhidzhoev
Date: 2024-10-07T14:50:01+02:00
New Revision: e7174a8378faf291e843892323527d001220d645
URL:
https://github.com/llvm/llvm-project/commit/e7174a8378faf291e843892323527d001220d645
DIFF:
https://github.com/llvm/llvm-project/commit/e7174a8378faf291e843892323527d001220d64
Michael137 wrote:
looks like we dont deal with `__builtin_printf` on Windows very well. Will fix
https://github.com/llvm/llvm-project/pull/33
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/
Da-Viper wrote:
> @Da-Viper do you have the necessary permissions to merge PRs by yourself? Or
> do you need somebody to merge this on your behalf?
I don't have permissions
https://github.com/llvm/llvm-project/pull/106919
___
lldb-commits mailing list
https://github.com/Michael137 approved this pull request.
Nice! thanks!
https://github.com/llvm/llvm-project/pull/111353
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
labath wrote:
It looks like the simulator tests are too smart for their own good. #111353
ought to fix this.
https://github.com/llvm/llvm-project/pull/110856
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mail
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Pavel Labath (labath)
Changes
…pping, which works by setting a field on the function object. This doesn't
work on a functools.partial object. Use a real function instead.
---
Full diff: https://github.com/llvm/llvm-project/pull/111353.diff
https://github.com/labath created
https://github.com/llvm/llvm-project/pull/111353
…pping, which works by setting a field on the function object. This doesn't
work on a functools.partial object. Use a real function instead.
>From 77e73b806a19cf42574eb36f096a15efac7f28ac Mon Sep 17 00:00:00 200
Author: Michael Buch
Date: 2024-10-07T11:12:01+01:00
New Revision: a1c0ba1646f5a80dadd34f55e4a36d5409c2675a
URL:
https://github.com/llvm/llvm-project/commit/a1c0ba1646f5a80dadd34f55e4a36d5409c2675a
DIFF:
https://github.com/llvm/llvm-project/commit/a1c0ba1646f5a80dadd34f55e4a36d5409c2675a.diff
https://github.com/Michael137 closed
https://github.com/llvm/llvm-project/pull/33
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Author: Michael Buch
Date: 2024-10-07T11:01:56+01:00
New Revision: 66713a0f8257661a8849e1a710a90b79576b0d21
URL:
https://github.com/llvm/llvm-project/commit/66713a0f8257661a8849e1a710a90b79576b0d21
DIFF:
https://github.com/llvm/llvm-project/commit/66713a0f8257661a8849e1a710a90b79576b0d21.diff
1 - 100 of 118 matches
Mail list logo
