https://github.com/nicovank updated
https://github.com/llvm/llvm-project/pull/106500
>From b86b6ca2a14d5e26bd00b5e72c194ee5fbe23f5d Mon Sep 17 00:00:00 2001
From: Nicolas van Kempen
Date: Thu, 29 Aug 2024 02:47:58 -0400
Subject: [PATCH] [NFC] Prefer subprocess.DEVNULL over os.devnull
There is
https://github.com/nicovank updated
https://github.com/llvm/llvm-project/pull/106500
>From b86b6ca2a14d5e26bd00b5e72c194ee5fbe23f5d Mon Sep 17 00:00:00 2001
From: Nicolas van Kempen
Date: Thu, 29 Aug 2024 02:47:58 -0400
Subject: [PATCH] [NFC] Prefer subprocess.DEVNULL over os.devnull
There is
llvmbot wrote:
@llvm/pr-subscribers-testing-tools
@llvm/pr-subscribers-clang
Author: Nicolas van Kempen (nicovank)
Changes
There is no need to support Python 2.7 anymore, Python 3.3+ has
`subprocess.DEVNULL`. This is good practice and also prevents file handles from
staying open unneces
https://github.com/nicovank created
https://github.com/llvm/llvm-project/pull/106500
There is no need to support Python 2.7 anymore, Python 3.3+ has
`subprocess.DEVNULL`. This is good practice and also prevents file handles from
staying open unnecessarily.
Also remove a couple unused or unne
https://github.com/medismailben requested changes to this pull request.
Let's make `std::optional offset_in_command` a default member of the
`CommandObject` base class to avoid changing all the `DoExecute`
implementations, even when not needed.
https://github.com/llvm/llvm-project/pull/106470
https://github.com/medismailben edited
https://github.com/llvm/llvm-project/pull/106470
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -2076,7 +2077,11 @@ bool CommandInterpreter::HandleCommand(const char
*command_line,
}
ElapsedTime elapsed(execute_time);
-cmd_obj->Execute(remainder.c_str(), result);
+size_t nchar = real_original_command_string.find(remainder);
+std::optional pos_in_c
https://github.com/Jlalond closed
https://github.com/llvm/llvm-project/pull/106473
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Author: Jacob Lalonde
Date: 2024-08-28T21:15:30-07:00
New Revision: 82ebd333a889d2372c8445dc3d5d527ec48537db
URL:
https://github.com/llvm/llvm-project/commit/82ebd333a889d2372c8445dc3d5d527ec48537db
DIFF:
https://github.com/llvm/llvm-project/commit/82ebd333a889d2372c8445dc3d5d527ec48537db.diff
https://github.com/Jlalond updated
https://github.com/llvm/llvm-project/pull/106473
>From 88a1a5d2b8698a5474bff0756012369401f7f433 Mon Sep 17 00:00:00 2001
From: Jacob Lalonde
Date: Wed, 28 Aug 2024 16:50:57 -0700
Subject: [PATCH 1/3] Have minidump read all registers as 64 and handle
truncatio
https://github.com/igorkudrin updated
https://github.com/llvm/llvm-project/pull/106478
>From 6854730d45a2c119d2b8f71df6e22ead1c7ad5a8 Mon Sep 17 00:00:00 2001
From: Igor Kudrin
Date: Wed, 28 Aug 2024 17:57:38 -0700
Subject: [PATCH] [lldb][AArch64] Do not crash if NT_ARM_TLS is missing
[D156118
jasonmolenda wrote:
Regarding #3 of my todo's
> debugserver on armv7k watches is doesn't correctly report a "step by
> breakpoint" as a trace event, need to verify that we can step / step past
> breakpoints correctly on old watches running that old debugserver.
I've tested the new breakpoint
https://github.com/jasonmolenda updated
https://github.com/llvm/llvm-project/pull/105594
>From 56ca564185bdceea25162a1ce3b1e8c8fa2641e2 Mon Sep 17 00:00:00 2001
From: Jason Molenda
Date: Fri, 19 Jul 2024 17:26:13 -0700
Subject: [PATCH 1/3] [lldb] Change lldb's breakpoint handling behavior
(#96
@@ -62,6 +63,17 @@ def verify_core_file(
# Try to read just past the red zone and fail
process.ReadMemory(sp - red_zone - 1, 1, error)
self.assertTrue(error.Fail(), "No failure when reading past the
red zone")
+# Verify the regis
@@ -62,6 +63,17 @@ def verify_core_file(
# Try to read just past the red zone and fail
process.ReadMemory(sp - red_zone - 1, 1, error)
self.assertTrue(error.Fail(), "No failure when reading past the
red zone")
+# Verify the regis
https://github.com/jeffreytan81 approved this pull request.
https://github.com/llvm/llvm-project/pull/106473
___
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: Igor Kudrin (igorkudrin)
Changes
[D156118](https://reviews.llvm.org/D156118) states that this note is always
present, but it is better to check it explicitly, as otherwise `lldb` may crash
when trying to read registers.
---
Full diff: htt
https://github.com/igorkudrin created
https://github.com/llvm/llvm-project/pull/106478
[D156118](https://reviews.llvm.org/D156118) states that this note is always
present, but it is better to check it explicitly, as otherwise `lldb` may crash
when trying to read registers.
>From e588c3c305323
https://github.com/jurahul closed
https://github.com/llvm/llvm-project/pull/106454
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Author: Rahul Joshi
Date: 2024-08-28T17:41:43-07:00
New Revision: b75fe11fd6fe751157012a8881ece2f247bd3887
URL:
https://github.com/llvm/llvm-project/commit/b75fe11fd6fe751157012a8881ece2f247bd3887
DIFF:
https://github.com/llvm/llvm-project/commit/b75fe11fd6fe751157012a8881ece2f247bd3887.diff
L
jimingham wrote:
> On Aug 28, 2024, at 3:43 PM, Michael Buch ***@***.***> wrote:
>
>
> yes. If we can do it, find something in the local compile unit first, if
> there are two symbols in the CU, then the public one, else the private.
>
> I guess here lies my hangup. What is the distinction
https://github.com/e-kwsm updated
https://github.com/llvm/llvm-project/pull/94034
>From fced0da5599e1979c13b53ac8b4ae6ff7d47003c Mon Sep 17 00:00:00 2001
From: Eisuke Kawashima
Date: Sat, 11 May 2024 02:39:21 +0900
Subject: [PATCH] fix(lldb/**.py): fix invalid escape sequences
---
lldb/exampl
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
af3ee626a396aa9ac9480131f48f6ebe2f6664c1...2e7f0469fb596dfd53142e1479ba3828ca00f48f
lldb
https://github.com/Jlalond edited
https://github.com/llvm/llvm-project/pull/106473
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
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
a7ba73bf614f6d147bd1cdaddee156bd85e31703...88a1a5d2b8698a5474bff0756012369401f7f433
lldb
https://github.com/Jlalond updated
https://github.com/llvm/llvm-project/pull/106473
>From 88a1a5d2b8698a5474bff0756012369401f7f433 Mon Sep 17 00:00:00 2001
From: Jacob Lalonde
Date: Wed, 28 Aug 2024 16:50:57 -0700
Subject: [PATCH 1/2] Have minidump read all registers as 64 and handle
truncatio
@@ -328,18 +328,19 @@ UserExpression::Evaluate(ExecutionContext &exe_ctx,
}
if (!parse_success) {
- std::string msg;
- {
-llvm::raw_string_ostream os(msg);
-if (!diagnostic_manager.Diagnostics().empty())
- os << diagnostic_manager.Get
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Jacob Lalonde (Jlalond)
Changes
This patch addresses a bug where `cs`/`gs` and other segmentation flags were
being identified as having a type of `32b` and `64b` for `rflags`. In that case
the register value was returning the fail value `0
https://github.com/Jlalond created
https://github.com/llvm/llvm-project/pull/106473
This patch addresses a bug where `cs`/`gs` and other segmentation flags were
being identified as having a type of `32b` and `64b` for `rflags`. In that case
the register value was returning the fail value `0xF.
@@ -130,13 +120,17 @@ class DiagnosticManager {
m_diagnostics.back()->AppendMessage(str);
}
- // Returns a string containing errors in this format:
- //
- // "error: error text\n
- // warning: warning text\n
- // remark text\n"
+ /// Returns a string containing e
@@ -65,6 +65,23 @@ std::string DiagnosticManager::GetString(char separator) {
return ret;
}
+Status DiagnosticManager::GetAsStatus(lldb::ExpressionResults result) {
+ llvm::SmallVector details;
+ details.reserve(m_diagnostics.size());
+ for (const auto &diagnostic : m_dia
https://github.com/jasonmolenda updated
https://github.com/llvm/llvm-project/pull/105594
>From 56ca564185bdceea25162a1ce3b1e8c8fa2641e2 Mon Sep 17 00:00:00 2001
From: Jason Molenda
Date: Fri, 19 Jul 2024 17:26:13 -0700
Subject: [PATCH 1/2] [lldb] Change lldb's breakpoint handling behavior
(#96
@@ -47,7 +48,34 @@ class Status {
/// into ValueType.
typedef uint32_t ValueType;
- Status();
+ /// A customizable "detail" for an error. For example, expression
+ /// evaluation failures often have more than one diagnostic that the
+ /// UI layer might want to render
https://github.com/adrian-prantl deleted
https://github.com/llvm/llvm-project/pull/106442
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -65,6 +65,23 @@ std::string DiagnosticManager::GetString(char separator) {
return ret;
}
+Status DiagnosticManager::GetAsStatus(lldb::ExpressionResults result) {
+ llvm::SmallVector details;
+ details.reserve(m_diagnostics.size());
+ for (const auto &diagnostic : m_dia
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Adrian Prantl (adrian-prantl)
Changes
This patch is a reworking of Pete Lawrence's (@PortalPete) proposal
for better expression evaluator error messages:
https://github.com/llvm/llvm-project/pull/80938
Before:
```
$ lldb -o "expr a+b"
(lld
adrian-prantl wrote:
FYI, this is where this is going:
https://github.com/llvm/llvm-project/pull/106470
https://github.com/llvm/llvm-project/pull/106442
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/l
https://github.com/adrian-prantl converted_to_draft
https://github.com/llvm/llvm-project/pull/106470
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Michael137 wrote:
> yes. If we can do it, find something in the local compile unit first, if
> there are two symbols in the CU, then the public one, else the private.
I guess here lies my hangup. What is the distinction between local and private
`lldb_private::Symbol`s here? And why prefer th
DmT021 wrote:
> Don't let us hold this patch up if returning the the original patch that
> fixes things makes things work if you can't easily get the same functionality
> from this version of the patch. Will one part of this patch work with the new
> stuff and the other part not? If so, maybe
https://github.com/ashgti updated
https://github.com/llvm/llvm-project/pull/105905
>From ebcf4842c7d6c5ac0da4976c9cffb68bc3b22807 Mon Sep 17 00:00:00 2001
From: John Harrison
Date: Fri, 23 Aug 2024 16:04:44 -0700
Subject: [PATCH 1/6] [lldb-dap] Improve `stackTrace` and `exceptionInfo` DAP
requ
github-actions[bot] wrote:
:warning: C/C++ code formatter, clang-format found issues in your code.
:warning:
You can test this locally with the following command:
``bash
git-clang-format --diff cdd11d694a406a98a16d6265168ee2fbe1b6a87c
7960402faaeabeba610cc56cba04638e355563c8 --e
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
cdd11d694a406a98a16d6265168ee2fbe1b6a87c...7960402faaeabeba610cc56cba04638e355563c8
lldb/
@@ -3106,80 +3228,105 @@ void request_stackTrace(const llvm::json::Object
&request) {
llvm::json::Array stackFrames;
llvm::json::Object body;
+ // Threads stacks may contain runtime specific extended backtraces, when
+ // constructing a stack trace first report the full
https://github.com/ashgti updated
https://github.com/llvm/llvm-project/pull/105905
>From ebcf4842c7d6c5ac0da4976c9cffb68bc3b22807 Mon Sep 17 00:00:00 2001
From: John Harrison
Date: Fri, 23 Aug 2024 16:04:44 -0700
Subject: [PATCH 1/5] [lldb-dap] Improve `stackTrace` and `exceptionInfo` DAP
requ
https://github.com/joker-eph approved this pull request.
https://github.com/llvm/llvm-project/pull/106454
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/jurahul updated
https://github.com/llvm/llvm-project/pull/106454
>From 581c47377f77a9d2819a5997b1c0a3c23b2c3346 Mon Sep 17 00:00:00 2001
From: Rahul Joshi
Date: Wed, 28 Aug 2024 13:55:58 -0700
Subject: [PATCH] [NFC] Fix formatv() usage in preparation of validation
Fix severa
github-actions[bot] wrote:
:warning: C/C++ code formatter, clang-format found issues in your code.
:warning:
You can test this locally with the following command:
``bash
git-clang-format --diff eb9c49c900f43aa79811f80847c97c6596197430
b97456af86580c7f2d4473fbc13d3e345f071486 --e
jurahul wrote:
Started https://github.com/llvm/llvm-project/pull/106454 for the independent
fixes.
https://github.com/llvm/llvm-project/pull/105745
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listin
llvmbot wrote:
@llvm/pr-subscribers-mlir
Author: Rahul Joshi (jurahul)
Changes
Fix several uses of formatv() that would be flagged as invalid by an upcoming
change that will add additional validation to formatv().
---
Full diff: https://github.com/llvm/llvm-project/pull/106454.diff
10
llvmbot wrote:
@llvm/pr-subscribers-clang
Author: Rahul Joshi (jurahul)
Changes
Fix several uses of formatv() that would be flagged as invalid by an upcoming
change that will add additional validation to formatv().
---
Full diff: https://github.com/llvm/llvm-project/pull/106454.diff
10
https://github.com/jurahul created
https://github.com/llvm/llvm-project/pull/106454
Fix several uses of formatv() that would be flagged as invalid by an upcoming
change that will add additional validation to formatv().
>From b97456af86580c7f2d4473fbc13d3e345f071486 Mon Sep 17 00:00:00 2001
Fro
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Andrew Rogers (andrurogerz)
Changes
## Purpose
Running the LLDB API tests against a remote Android target with NDK version r22
or later fails to compile the test inferiors. NDK r21 from 2021 is the most
recent NDK that still works with the
https://github.com/andrurogerz ready_for_review
https://github.com/llvm/llvm-project/pull/106443
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/andrurogerz edited
https://github.com/llvm/llvm-project/pull/106443
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
jurahul wrote:
> LGTM
Thanks. I'll split out an additional PR for the independent fixes, and then in
this one I'll change ENABLE_VALIDATION back to 0 and also remove the
`formatvv()` and use `formatv(false` instead so we just have one function name.
https://github.com/llvm/llvm-project/pull/1
@@ -143,15 +140,76 @@ formatv_object_base::splitLiteralAndReplacement(StringRef
Fmt) {
return std::make_pair(ReplacementItem{Fmt}, StringRef());
}
+#ifndef NDEBUG
+#define ENABLE_VALIDATION 1
+#else
+#define ENABLE_VALIDATION 1 // Convienently enable validation in release m
https://github.com/joker-eph approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/105745
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/joker-eph edited
https://github.com/llvm/llvm-project/pull/105745
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -655,7 +655,7 @@ DWARFUnit::GetDIE(dw_offset_t die_offset) {
if (!ContainsDIEOffset(die_offset)) {
GetSymbolFileDWARF().GetObjectFile()->GetModule()->ReportError(
-"GetDIE for DIE {0:x16} is outside of its CU {0:x16}", die_offset,
+"GetDIE for DIE {0:x
@@ -655,7 +655,7 @@ DWARFUnit::GetDIE(dw_offset_t die_offset) {
if (!ContainsDIEOffset(die_offset)) {
GetSymbolFileDWARF().GetObjectFile()->GetModule()->ReportError(
-"GetDIE for DIE {0:x16} is outside of its CU {0:x16}", die_offset,
+"GetDIE for DIE {0:x
jurahul wrote:
Looks like the CI builds are release but with LLVM_ENABLE_ASSERTION=ON, so this
validation code will be enabled and potential bad usage will be flagged as well
going forward as long as it's exercised during the build or test.
https://github.com/llvm/llvm-project/pull/105745
https://github.com/jeffreytan81 closed
https://github.com/llvm/llvm-project/pull/104532
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Author: jeffreytan81
Date: 2024-08-28T13:34:35-07:00
New Revision: 38b252aa45abad53d7c07c666569b174a215d94d
URL:
https://github.com/llvm/llvm-project/commit/38b252aa45abad53d7c07c666569b174a215d94d
DIFF:
https://github.com/llvm/llvm-project/commit/38b252aa45abad53d7c07c666569b174a215d94d.diff
@@ -65,6 +65,23 @@ std::string DiagnosticManager::GetString(char separator) {
return ret;
}
+Status DiagnosticManager::GetAsStatus(lldb::ExpressionResults result) {
+ llvm::SmallVector details;
+ details.reserve(m_diagnostics.size());
+ for (const auto &diagnostic : m_dia
@@ -328,18 +328,19 @@ UserExpression::Evaluate(ExecutionContext &exe_ctx,
}
if (!parse_success) {
- std::string msg;
- {
-llvm::raw_string_ostream os(msg);
-if (!diagnostic_manager.Diagnostics().empty())
- os << diagnostic_manager.Get
@@ -130,13 +120,17 @@ class DiagnosticManager {
m_diagnostics.back()->AppendMessage(str);
}
- // Returns a string containing errors in this format:
- //
- // "error: error text\n
- // warning: warning text\n
- // remark text\n"
+ /// Returns a string containing e
@@ -47,7 +48,34 @@ class Status {
/// into ValueType.
typedef uint32_t ValueType;
- Status();
+ /// A customizable "detail" for an error. For example, expression
+ /// evaluation failures often have more than one diagnostic that the
+ /// UI layer might want to render
jimingham wrote:
"Detail" seems too generic a name for what is a very "compiler error" centric
data structure in Status. But if it's ExprDetail, then the next time someone
wants to add richer info about an error, would we have them add an
`OtherErrorDetail` structure? Maybe the latter questi
https://github.com/andrurogerz edited
https://github.com/llvm/llvm-project/pull/106443
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -47,7 +48,34 @@ class Status {
/// into ValueType.
typedef uint32_t ValueType;
- Status();
+ /// A customizable "detail" for an error. For example, expression
+ /// evaluation failures often have more than one diagnostic that the
+ /// UI layer might want to render
https://github.com/andrurogerz edited
https://github.com/llvm/llvm-project/pull/106443
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/andrurogerz edited
https://github.com/llvm/llvm-project/pull/106443
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/jimingham approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/104532
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/andrurogerz created
https://github.com/llvm/llvm-project/pull/106443
Running the LLDB API tests against a remote Android target with NDK version r22
or later fails when compiling the test inferiors.
## Problem Details
Android introduced a unified tools layout in NDK r19 (201
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Adrian Prantl (adrian-prantl)
Changes
…NFC]
This patch is the first patch in a series reworking of Pete Lawrence's (@PortalPete) amazing proposal for better expression evaluator error messages
(https://github.com/llvm/llvm-project/pull/809
https://github.com/adrian-prantl created
https://github.com/llvm/llvm-project/pull/106442
…NFC]
This patch is the first patch in a series reworking of Pete Lawrence's
(@PortalPete) amazing proposal for better expression evaluator error messages
(https://github.com/llvm/llvm-project/pull/80938
jurahul wrote:
I have uploaded a new version where the validation is enabled only in debug
builds, and also added a benchmark for formatv(). On my machine, the benchmark
results are as follows:
```
Old:
BM_FormatVariadic_mean 3427456 ns 3427426 ns 10
New
BM_FormatVariadic_
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
907c7eb311077c5da434bf67858b1173a351d800...f9275093d59c73fe99a0079d06ed61532775385c
lldb/
@@ -102,15 +102,33 @@ endif
# If you change the defaults of CC, be sure to also change it in the file
# test/builders/builder_base.py, which provides a Python way to return the
# value of the make variable CC -- getCompiler().
-#
-# See also these functions:
-# o cxx_compiler
https://github.com/dzhidzhoev updated
https://github.com/llvm/llvm-project/pull/102185
>From e40ca68a934d0595ebc6c07010a4f6a814fa026f Mon Sep 17 00:00:00 2001
From: Vladislav Dzhidzhoev
Date: Sat, 27 Jul 2024 02:39:32 +0200
Subject: [PATCH 1/5] [lldb][test] Improve toolchain detection in
Makef
https://github.com/jurahul updated
https://github.com/llvm/llvm-project/pull/105745
>From d805dcdc44d22bb21d086b186cc7f644323f68ef Mon Sep 17 00:00:00 2001
From: Rahul Joshi
Date: Thu, 22 Aug 2024 08:47:02 -0700
Subject: [PATCH] [Support] Detect invalid formatv() calls
- Detect formatv() calls
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Jordan R AW (ajordanr-google)
Changes
armv7a and armv8a are common names for the application subarch for arm.
These names in particular are used in ChromeOS, Android, and a few other known
applications. In ChromeOS, we encountered a bug wh
https://github.com/ajordanr-google created
https://github.com/llvm/llvm-project/pull/106433
armv7a and armv8a are common names for the application subarch for arm.
These names in particular are used in ChromeOS, Android, and a few other known
applications. In ChromeOS, we encountered a bug whe
jeffreytan81 wrote:
@jimingham, right, I am pretty sure that Microsoft Visual Studio debugger
implements step-over breakpoint the same as lldb so it is a universal standard
behavior and I haven't heard anyone really complaining about this.
Based on this, if there is no further concern, anyone
labath wrote:
I figured out the problem, and it's kind of hilarious. Turns out (linux?)
lldb-server does not actually return partial reads (i.e., it behaves like
windows), but the reason that the test succeeds (for me) is that the holes in
the allocated memory get filled my memory allocated by
JDevlieghere wrote:
Looks like this is ready to go. @Da-Viper do you need someone to merge this for
you?
https://github.com/llvm/llvm-project/pull/104711
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman
@@ -3106,80 +3228,105 @@ void request_stackTrace(const llvm::json::Object
&request) {
llvm::json::Array stackFrames;
llvm::json::Object body;
+ // Threads stacks may contain runtime specific extended backtraces, when
+ // constructing a stack trace first report the full
clayborg wrote:
> I think Greg is saying that if we don't find a local symbol, and don't find
> the symbol in the global symbols of the current module, then we should search
> all the other modules, but in that case preferring external symbols to
> internal since those are the ones that are po
slydiman wrote:
LGTM,
but it is necessary to debug the test and make it more stable (it is still red).
I assumed that something is wrong with the first resize() because of capacity=0.
> I'm using the SmallVector for the resize_for_overwrite functionality
> (allocating memory without initializi
Author: David Spickett
Date: 2024-08-28T16:51:45Z
New Revision: af3ee626a396aa9ac9480131f48f6ebe2f6664c1
URL:
https://github.com/llvm/llvm-project/commit/af3ee626a396aa9ac9480131f48f6ebe2f6664c1
DIFF:
https://github.com/llvm/llvm-project/commit/af3ee626a396aa9ac9480131f48f6ebe2f6664c1.diff
LOG
jimingham wrote:
I think Greg is saying that if we don't find a local symbol, and don't find the
symbol in the global symbols of the current module, then we should search all
the other modules, but in that case preferring external symbols to internal
since those are the ones that are potential
mbucko wrote:
Closing this PR in favor of #104193
https://github.com/llvm/llvm-project/pull/102536
___
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/102536
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -1,9 +1,79 @@
-#include
-#include
-
-int main (int argc, char const *argv[])
-{
-const char* stringdata = "hello world; I like to write text in const char
pointers";
-uint8_t bytedata[] =
{0xAA,0xBB,0xCC,0xDD,0xEE,0xFF,0x00,0x11,0x22,0x33,0x44,0x55,0x66,0x77,0x88,0x
@@ -3367,21 +3340,48 @@ lldb::addr_t Process::FindInMemory(lldb::addr_t low,
lldb::addr_t high,
if (region_size < size)
return LLDB_INVALID_ADDRESS;
+ // See "Boyer-Moore string search algorithm".
std::vector bad_char_heuristic(256, size);
- ProcessMemoryIterator i
@@ -3367,21 +3340,48 @@ lldb::addr_t Process::FindInMemory(lldb::addr_t low,
lldb::addr_t high,
if (region_size < size)
return LLDB_INVALID_ADDRESS;
+ // See "Boyer-Moore string search algorithm".
std::vector bad_char_heuristic(256, size);
- ProcessMemoryIterator i
@@ -1,9 +1,76 @@
-#include
-#include
-
-int main (int argc, char const *argv[])
-{
-const char* stringdata = "hello world; I like to write text in const char
pointers";
-uint8_t bytedata[] =
{0xAA,0xBB,0xCC,0xDD,0xEE,0xFF,0x00,0x11,0x22,0x33,0x44,0x55,0x66,0x77,0x88,0x
@@ -3367,21 +3340,48 @@ lldb::addr_t Process::FindInMemory(lldb::addr_t low,
lldb::addr_t high,
if (region_size < size)
return LLDB_INVALID_ADDRESS;
+ // See "Boyer-Moore string search algorithm".
std::vector bad_char_heuristic(256, size);
- ProcessMemoryIterator i
@@ -3367,21 +3340,48 @@ lldb::addr_t Process::FindInMemory(lldb::addr_t low,
lldb::addr_t high,
if (region_size < size)
return LLDB_INVALID_ADDRESS;
+ // See "Boyer-Moore string search algorithm".
std::vector bad_char_heuristic(256, size);
- ProcessMemoryIterator i
1 - 100 of 119 matches
Mail list logo
