https://bugs.llvm.org/show_bug.cgi?id=44146
Bug ID: 44146
Summary: Incorrect step-over behavior falling through functions
Product: lldb
Version: 9.0
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
On 23 Nov 2019, at 07:20, Tom Stellard via Release-testers
wrote:
>
> I've tagged the LLVM 9.0.1-rc1 release. Testers can begin testing and upload
> binaries. I've also updated the test-release.sh script to pull from GitHub
> instead of SVN, if you run into any issues with the new script, let
Here's an interesting bug, in source/Utility/DataExtractor.cpp,
DataExtractor::GetMaxU64Bitfield:
uint64_t bitfield_mask = ((1ul << bitfield_bit_size) - 1);
In Visual Studio 2017, ul is a 32 bit type. When I run it with a size of 36
(from large_packed in test/API/lang/c/bitfields/main.c), I
https://bugs.llvm.org/show_bug.cgi?id=44132
Bug ID: 44132
Summary: TestReturnValue.py fails on AArch64 Ubuntu
Product: lldb
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
On Mon, 25 Nov 2019, Pavel Labath wrote:
So, what elf linkers do is that they link non-loadable (SHF_ALLOC) sections
as if they were loaded at address zero. I think it's possible to change that
via a linker script, but I think doing that would cause pretty much
everything to blow up.
This me
On 25/11/2019 10:46, Martin Storsjö wrote:
On Mon, 25 Nov 2019, Pavel Labath wrote:
On 24/11/2019 23:16, Martin Storsjö via lldb-dev wrote:
Hi,
I'm looking into something that seems like an inconsistency in
handling of the CIE pointer in FDEs in .debug_frame, between how
debug info is gener
On Mon, 25 Nov 2019, Martin Storsjö via lldb-dev wrote:
But now I tested this a bit more with ELF setups, and realized that it
somehow does seem to do the right thing. It might have something to do with
how ELF linkers handle this kind of section that isn't loaded at runtime (and
thus perhaps
On Mon, 25 Nov 2019, Pavel Labath wrote:
On 24/11/2019 23:16, Martin Storsjö via lldb-dev wrote:
Hi,
I'm looking into something that seems like an inconsistency in handling of
the CIE pointer in FDEs in .debug_frame, between how debug info is
generated in LLVM and consumed in LLDB.
For FDE
On 24/11/2019 23:16, Martin Storsjö via lldb-dev wrote:
Hi,
I'm looking into something that seems like an inconsistency in handling
of the CIE pointer in FDEs in .debug_frame, between how debug info is
generated in LLVM and consumed in LLDB.
For FDEs in .eh_frame, the CIE pointer/cie_id fiel
