https://github.com/kamleshbhalui created
https://github.com/llvm/llvm-project/pull/81451
Storing Larger bitwidth causes problem when byteswapping.
>From 51347e2de532261cfe980b299baeceb7747b7d48 Mon Sep 17 00:00:00 2001
From: Kamlesh Kumar
Date: Mon, 12 Feb 2024 13:30:32 +0530
Subject: [PATCH]
https://github.com/kamleshbhalui updated
https://github.com/llvm/llvm-project/pull/81451
>From 51347e2de532261cfe980b299baeceb7747b7d48 Mon Sep 17 00:00:00 2001
From: Kamlesh Kumar
Date: Mon, 12 Feb 2024 13:30:32 +0530
Subject: [PATCH 1/2] [lldb] Store proper integer bitwidth in Scalar Type
St
kamleshbhalui wrote:
There is not a test scenario in lldb itself.
https://github.com/llvm/llvm-project/pull/81451
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
kamleshbhalui wrote:
> This uses `DataExtractor::GetMaxU64` which already does this under the hood.
> What does this do that isn't already being done? It may help if you add a
> test case to show what you are trying to fix.
The problem with GetMaxU64 is that it always returns uint64_t even tho
kamleshbhalui wrote:
@clayborg @bulbazord
we have extension in lldb to support cobol code debugging, we require
byteswapping there. upstream version of lldb does not do byteswapping on scalar
so no problem seen.
https://github.com/llvm/llvm-project/pull/81451
_
kamleshbhalui wrote:
I think this PR https://reviews.llvm.org/D121408 introduced the current code,
which causing the problem.
https://github.com/llvm/llvm-project/pull/81451
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.
kamleshbhalui wrote:
> > > This uses `DataExtractor::GetMaxU64` which already does this under the
> > > hood. What does this do that isn't already being done? It may help if you
> > > add a test case to show what you are trying to fix.
> >
> >
> > @clayborg @bulbazord The problem with GetMaxU
kamleshbhalui wrote:
> > @clayborg @bulbazord we have extension in lldb to support cobol code
> > debugging, we require byteswapping there. upstream version of lldb does not
> > do byteswapping on scalar so no problem seen.
>
> Maybe not, but this should still be testable with a unit test. If
@@ -857,10 +857,18 @@ static Scalar DerefSizeExtractDataHelper(uint8_t
*addr_bytes,
DataExtractor addr_data(addr_bytes, size_addr_bytes, byte_order, size);
lldb::offset_t addr_data_offset = 0;
- if (size <= 8)
-return addr_data.GetMaxU64(&addr_data_offset, size);
-
kamleshbhalui wrote:
> I am fine with this patch if we fix the Scalar class to obey the bit width as
> suggested above. I do worry though that other Scalar values in the expression
> might get set to 64 bit values all of the time and cause problems with DWARF
> expressions. Do you have a code
https://github.com/kamleshbhalui created
https://github.com/llvm/llvm-project/pull/110822
On AArch64, TLS variables do not have DT_Location entries generated in the
debug information due to the lack of dtpoff relocation support, unlike on
x86_64. LLDB relies on this location info to calculate
https://github.com/kamleshbhalui updated
https://github.com/llvm/llvm-project/pull/110822
>From f36d8a2346be90b6bf5d68a7cec0bcf2d41cbd99 Mon Sep 17 00:00:00 2001
From: Kamlesh Kumar
Date: Thu, 19 Sep 2024 18:57:14 +0200
Subject: [PATCH] [LLDB] Enable TLS Variable Debugging Without Location Info
https://github.com/kamleshbhalui updated
https://github.com/llvm/llvm-project/pull/110822
>From ba3071566ac697e750606c7fc941e5f6fc738367 Mon Sep 17 00:00:00 2001
From: Kamlesh Kumar
Date: Thu, 19 Sep 2024 18:57:14 +0200
Subject: [PATCH] [LLDB] Enable TLS Variable Debugging Without Location Info
kamleshbhalui wrote:
> The implementation of Variable::IsThreadLocal is most likely a non-starter,
> as it introduces a relatively expensive operation on the common variable
> update path for all variables. Doing this (once) at variable creation would
> be better, but I still have very big res
14 matches
Mail list logo
