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
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 field is interpreted as an
offset from the current FDE - thi
