[lldb-dev] [Bug 44146] New: Incorrect step-over behavior falling through functions
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 Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: wirel...@gmail.com CC: jdevliegh...@apple.com, llvm-b...@lists.llvm.org $ cat fallthrough.s .globl main, _main main: _main: push %rbp main2: call subroutine pop %rbp ret subroutine: xor %eax, %eax ret $ cc fallthrough.s -o fallthrough $ lldb ./fallthrough -o 'breakpoint set -n main' -o 'process launch' On macOS, "next / next" stops at fallthrough`subroutine instead of correctly stepping over the call. On Linux, "next" finishes the process instead of stepping one instruction. -- You are receiving this mail because: You are the assignee for the bug.___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [Release-testers] LLVM 9.0.1-rc1 Release has been tagged
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 me know. For this rc, I used two patches, from: * https://bugs.llvm.org/show_bug.cgi?id=42892 - After r356631, Sanitizer-i386-Test faills to link on FreeBSD * https://bugs.llvm.org/show_bug.cgi?id=42894 - FreeBSD needs -pthread link flag for dynamic ASan tests Uploaded: SHA256 (clang+llvm-9.0.1-rc1-amd64-unknown-freebsd11.tar.xz) = daeac75e0b6015940cf945d4e0bd173787db8b16e42c20ae0c5deafdadeeb1e7 SHA256 (clang+llvm-9.0.1-rc1-i386-unknown-freebsd11.tar.xz) = b29869f2aed037926c98ac66d3ad145ffb42137b317bbcd6e1927ed1de08794f Main test results on amd64-freebsd11: Testing Time: 7179.26s Unexpected Passing Tests (6): AddressSanitizer-i386-freebsd-dynamic :: TestCases/interception_failure_test.cc AddressSanitizer-x86_64-freebsd-dynamic :: TestCases/interception_failure_test.cc lldb-Suite :: api/multiple-targets/TestMultipleTargets.py lldb-Suite :: functionalities/data-formatter/data-formatter-skip-summary/TestDataFormatterSkipSummary.py lldb-Suite :: lang/cpp/namespace/TestNamespaceLookup.py lldb-Suite :: python_api/thread/TestThreadAPI.py Failing Tests (475): AddressSanitizer-Unit :: ./Asan-i386-calls-Dynamic-Test/AddressSanitizer.ShadowGapTest AddressSanitizer-Unit :: ./Asan-i386-inline-Dynamic-Test/AddressSanitizer.ShadowGapTest AddressSanitizer-i386-freebsd :: TestCases/Posix/fread_fwrite.cc AddressSanitizer-i386-freebsd-dynamic :: TestCases/Posix/fread_fwrite.cc Builtins-i386-freebsd :: floatundixf_test.c LLDB :: ExecControl/StopHook/stop-hook-threads.test LLDB :: ExecControl/StopHook/stop-hook.test LLDB :: SymbolFile/DWARF/find-basic-namespace.cpp LLDB :: SymbolFile/DWARF/find-basic-variable.cpp LLDB :: SymbolFile/DWARF/find-method.cpp LLDB :: tools/lldb-mi/exec/exec-step.test LLVM :: tools/yaml2obj/elf-override-shoffset.yaml LLVM :: tools/yaml2obj/elf-override-shsize.yaml MemorySanitizer-Unit :: ./Msan-x86_64-Test/MemorySanitizer.SmallPreAllocatedStackThread MemorySanitizer-Unit :: ./Msan-x86_64-Test/MemorySanitizer.bind_getsockname MemorySanitizer-Unit :: ./Msan-x86_64-Test/MemorySanitizer.confstr MemorySanitizer-Unit :: ./Msan-x86_64-Test/MemorySanitizer.mbrtowc MemorySanitizer-Unit :: ./Msan-x86_64-Test/MemorySanitizer.swprintf MemorySanitizer-Unit :: ./Msan-x86_64-Test/MemorySanitizer.valloc MemorySanitizer-Unit :: ./Msan-x86_64-with-call-Test/MemorySanitizer.SmallPreAllocatedStackThread MemorySanitizer-Unit :: ./Msan-x86_64-with-call-Test/MemorySanitizer.bind_getsockname MemorySanitizer-Unit :: ./Msan-x86_64-with-call-Test/MemorySanitizer.confstr MemorySanitizer-Unit :: ./Msan-x86_64-with-call-Test/MemorySanitizer.mbrtowc MemorySanitizer-Unit :: ./Msan-x86_64-with-call-Test/MemorySanitizer.swprintf MemorySanitizer-Unit :: ./Msan-x86_64-with-call-Test/MemorySanitizer.valloc MemorySanitizer-X86_64 :: dtls_test.c MemorySanitizer-lld-X86_64 :: dtls_test.c SanitizerCommon-asan-i386-FreeBSD :: Posix/devname_r.cc SanitizerCommon-asan-i386-FreeBSD :: Posix/weak_hook_test.cc SanitizerCommon-asan-x86_64-FreeBSD :: Posix/weak_hook_test.cc SanitizerCommon-msan-x86_64-FreeBSD :: FreeBSD/capsicum.cc SanitizerCommon-msan-x86_64-FreeBSD :: Posix/dedup_token_length_test.cc SanitizerCommon-msan-x86_64-FreeBSD :: Posix/weak_hook_test.cc SanitizerCommon-tsan-x86_64-FreeBSD :: FreeBSD/capsicum.cc SanitizerCommon-tsan-x86_64-FreeBSD :: FreeBSD/fdevname.cc SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/arc4random.cc SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/dedup_token_length_test.cc SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/devname.cc SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/devname_r.cc SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/dump_instruction_bytes.cc SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/fpe.cc SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/fputc_putc_putchar.cc SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/fputs_puts.cc SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/fseek.cc SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/fts.cc SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/funopen.cc SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/getfsent.cc SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/getmntinfo.cc SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/getpass.cc SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/getusershell.cc SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/illegal_read_test.cc
[lldb-dev] Possible bug in DataExtractor::GetMaxU64Bitfield
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 get a mask of 0x0f. I think that should be 1ull, or (uint64_t) 1, not 1ul. MSDN problem talking about the size of ul: https://developercommunity.visualstudio.com/content/problem/226112/vs2017-1ul-32-is-evaluated-to-0-in-watch-window-du.html Thoughts? ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 44132] New: TestReturnValue.py fails on AArch64 Ubuntu
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
Priority: P
Component: All Bugs
Assignee: lldb-dev@lists.llvm.org
Reporter: diana.pi...@linaro.org
CC: jdevliegh...@apple.com, llvm-b...@lists.llvm.org
test_vector_values_dwarf/dwo fails for return_vector_size_float32_32 and
return_ext_vector_size_float32_8
test_with_python_dwarf/dwo fails for most cases
The error messages are of this kind:
File
"/home/buildslave/buildslave/lldb-cmake-aarch64/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py",
line 1732, in test_method
return attrvalue(self)
File
"/home/buildslave/buildslave/lldb-cmake-aarch64/llvm-project/lldb/packages/Python/lldbsuite/test/decorators.py",
line 111, in wrapper
func(*args, **kwargs)
File
"/home/buildslave/buildslave/lldb-cmake-aarch64/llvm-project/lldb/packages/Python/lldbsuite/test/decorators.py",
line 111, in wrapper
func(*args, **kwargs)
File
"/home/buildslave/buildslave/lldb-cmake-aarch64/llvm-project/lldb/packages/Python/lldbsuite/test/decorators.py",
line 111, in wrapper
func(*args, **kwargs)
File
"/home/buildslave/buildslave/lldb-cmake-aarch64/llvm-project/lldb/packages/Python/lldbsuite/test/decorators.py",
line 111, in wrapper
func(*args, **kwargs)
File
"/home/buildslave/buildslave/lldb-cmake-aarch64/llvm-project/lldb/packages/Python/lldbsuite/test/functionalities/return-value/TestReturnValue.py",
line 127, in test_with_python
self.return_and_test_struct_value("return_one_int")
File
"/home/buildslave/buildslave/lldb-cmake-aarch64/llvm-project/lldb/packages/Python/lldbsuite/test/decorators.py",
line 141, in wrapper
func(*args, **kwargs)
File
"/home/buildslave/buildslave/lldb-cmake-aarch64/llvm-project/lldb/packages/Python/lldbsuite/test/functionalities/return-value/TestReturnValue.py",
line 265, in return_and_test_struct_value
self.assertTrue(ret_value.IsValid())
AssertionError: False is not True
--
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Inconsistencies in CIE pointer in FDEs in .debug_frame
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 means that the whole absolute vs. section-relative inconsistency is irrelevant there (and I would expect the elf folks would not even consider that a inconsistency/bug). Ah, thanks - that does explain it. Yeah, in COFF, all sections, even non-loaded ones (IMAGE_SCN_MEM_DISCARDABLE) are assigned virtual addresses as if they actually were loaded. // Martin ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Inconsistencies in CIE pointer in FDEs in .debug_frame
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 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 - this seems to be consistent.
But for cases in .debug_frame, they are treated differently. In LLDB,
the cie_id field is assumed to be relative to the begin of the
.debug_frame section:
https://github.com/llvm/llvm-project/blob/master/lldb/source/Symbol/DWARFCallFrameInfo.cpp#L482-L495
However, when this field is produced in LLVM, it can, depending on
MCAsmInfo flags, end up written as a plain absolute address to the
CIE:
https://github.com/llvm/llvm-project/blob/master/llvm/lib/MC/MCDwarf.cpp#L1699-L1705
That code in MCDwarf.cpp hasn't been touched in many years, so I
would expect that the info it generates actually has been used since
and been found to be correct. Or are most cases built with
-funwind-tables or similar, enabled by default?, so this is exercised
in untested cases?
In the case where I'm running in this, LLDB reports "error: Invalid
cie offset" when running executables with such .debug_frame sections.
By adding an ", true" to the end of the EmitSymbolValue call in
MCDwarf.cpp, the symbol reference is made section relative and the
code seems to do what LLDB expects. Is that correct, or should LLDB
learn the cases (which?) where the cie_id is an absolute address
instead of a section relative one?
// Martin
What's the target you're encountering this behavior on? Can you maybe
provide a short example of how the CIE/FDE entries in question look like?
I'm seeing this behaviour for mingw targets. GCC produces debug_frame
sections where the CIE pointer is a section relative address (with a
SECTREL relocation), while LLVM produces debug_frame sections with
absolute (global/virtual) addresses.
Right. That's the part I was missing. Thanks.
LLDB seems to expect the format that GCC produces here.
I could be wrong (I'm not really an expert on this), but my
understanding is that
"asmInfo->doesDwarfUseRelocationsAcrossSections()" is basically
equivalent to "is target MachO"
Yes, that's pretty much my take of it as well. The BPF target also has
an option for setting this flag in asminfo, but other than that, it's
not modified >
That said, if that is all there is here, then it does not seem to me
like there's any special support in lldb needed, as the cie offset
will always be a correct absolute offset from the start of the section
by the time lldb gets to see it (and so it shouldn't matter if the
offset was put there by the compiler or the linker). This makes me
think that I am missing something, but I have no idea what could that
be..
This wasn't the inconsistency I'm looking into.
I'm looking into an inconsistency between section relative and absolute
addresses. The default case in MCDwarf.cpp, calls
EmitSymbolValue(, 4).
By default EmitSymbolValue emits _absolute_ addresses (or more
precisely, relocations that makes the linker produce absolute
addresses), i.e. the full address of the CIE, instead of section relative.
The EmitSymbolValue function, declared at
https://github.com/llvm/llvm-project/blob/master/llvm/include/llvm/MC/MCStreamer.h#L669-L670,
takes an IsSectionRelative parameter, which defaults to false here (as
it isn't specified). I would expect that it should be true, as LLDB
expects a section relative address here.
I think this is a bug in LLVM's MCDwarf.cpp, but it puzzles me how it
can have gone unnoticed.
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 doesn't really have a virtual address assigned).
So that pretty much clears the question regarding inconsistency, and
raises more questions about how this really works in ELF and MCDwarf.
A test procedure that shows off the issue is this:
$ cat test.c
void entry(void) { }
$ bin/clang -fno-unwind-tables test.c -c -g -o test.o -target
i686-linux-gnu
$ bin/llvm-objdump -r test.o
test.o: file format ELF32-i386
RELOCATION RECORDS FOR [.debug_frame]:
0018 R_386_32 .debug_frame
001c R_386_32 .text
# As far as I know, these two R_386_32 relocations both indicate that the
# full, absolute address of these two locations should be inserted in
# these two locations.
$ bin/ld.lld test.o -o exe -e entry
$ bin/llvm-dwarfdump --eh-frame exe
exe: file format ELF32-i386
.debug_frame contents:
0010 CIE
0014 0018 FDE cie= pc=004010c0...004010c5
^
# The CIE offset, the
Re: [lldb-dev] Inconsistencies in CIE pointer in FDEs in .debug_frame
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 doesn't really have a virtual address assigned). So that pretty much clears the question regarding inconsistency, and raises more questions about how this really works in ELF and MCDwarf. So, if I make the call to EmitSymbolValue() set the IsSectionRelative parameter to true, I get the correct, expected relocations for this section: RELOCATION RECORDS FOR [.debug_frame]: 0018 IMAGE_REL_I386_SECREL .debug_frame 001c IMAGE_REL_I386_DIR32 .text This matches what GCC produces in similar cases as well. But with this in place, ELF targets misbehave severely; there's no relocation produced at all for the .debug_frame symbol, and the second relocation gets written at the wrong offset. Ok, it turns out that there's already a flag that indicates exactly this, asmInfo->needsDwarfSectionOffsetDirective(), which just seems to not be used here where it should, which seems to encapsulate whether a certain type of relocation needs to be used (like in COFF) or if different section types like in ELF seems to handle it automatically with just one kind of relocation. I had seen it before but didn't really understand its role until I saw how ELF behaved. So this is clearly a closed case, and I'll be sending a patch for MCDwarf soon. // Martin ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Inconsistencies in CIE pointer in FDEs in .debug_frame
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 FDEs in .eh_frame, the CIE pointer/cie_id field is interpreted as an
offset from the current FDE - this seems to be consistent.
But for cases in .debug_frame, they are treated differently. In LLDB, the
cie_id field is assumed to be relative to the begin of the .debug_frame
section:
https://github.com/llvm/llvm-project/blob/master/lldb/source/Symbol/DWARFCallFrameInfo.cpp#L482-L495
However, when this field is produced in LLVM, it can, depending on
MCAsmInfo flags, end up written as a plain absolute address to the CIE:
https://github.com/llvm/llvm-project/blob/master/llvm/lib/MC/MCDwarf.cpp#L1699-L1705
That code in MCDwarf.cpp hasn't been touched in many years, so I would
expect that the info it generates actually has been used since and been
found to be correct. Or are most cases built with -funwind-tables or
similar, enabled by default?, so this is exercised in untested cases?
In the case where I'm running in this, LLDB reports "error: Invalid cie
offset" when running executables with such .debug_frame sections.
By adding an ", true" to the end of the EmitSymbolValue call in
MCDwarf.cpp, the symbol reference is made section relative and the code
seems to do what LLDB expects. Is that correct, or should LLDB learn the
cases (which?) where the cie_id is an absolute address instead of a section
relative one?
// Martin
What's the target you're encountering this behavior on? Can you maybe provide
a short example of how the CIE/FDE entries in question look like?
I'm seeing this behaviour for mingw targets. GCC produces debug_frame
sections where the CIE pointer is a section relative address (with a
SECTREL relocation), while LLVM produces debug_frame sections with
absolute (global/virtual) addresses.
LLDB seems to expect the format that GCC produces here.
I could be wrong (I'm not really an expert on this), but my understanding is
that "asmInfo->doesDwarfUseRelocationsAcrossSections()" is basically
equivalent to "is target MachO"
Yes, that's pretty much my take of it as well. The BPF target also has an
option for setting this flag in asminfo, but other than that, it's not
modified.
That said, if that is all there is here, then it does not seem to me like
there's any special support in lldb needed, as the cie offset will always be
a correct absolute offset from the start of the section by the time lldb gets
to see it (and so it shouldn't matter if the offset was put there by the
compiler or the linker). This makes me think that I am missing something, but
I have no idea what could that be..
This wasn't the inconsistency I'm looking into.
I'm looking into an inconsistency between section relative and absolute
addresses. The default case in MCDwarf.cpp, calls
EmitSymbolValue(, 4).
By default EmitSymbolValue emits _absolute_ addresses (or more precisely,
relocations that makes the linker produce absolute addresses), i.e. the
full address of the CIE, instead of section relative.
The EmitSymbolValue function, declared at
https://github.com/llvm/llvm-project/blob/master/llvm/include/llvm/MC/MCStreamer.h#L669-L670,
takes an IsSectionRelative parameter, which defaults to false here (as it
isn't specified). I would expect that it should be true, as LLDB expects a
section relative address here.
I think this is a bug in LLVM's MCDwarf.cpp, but it puzzles me how it can
have gone unnoticed.
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 doesn't really have a virtual address assigned).
So that pretty much clears the question regarding inconsistency, and
raises more questions about how this really works in ELF and MCDwarf.
A test procedure that shows off the issue is this:
$ cat test.c
void entry(void) { }
$ bin/clang -fno-unwind-tables test.c -c -g -o test.o -target i686-linux-gnu
$ bin/llvm-objdump -r test.o
test.o: file format ELF32-i386
RELOCATION RECORDS FOR [.debug_frame]:
0018 R_386_32 .debug_frame
001c R_386_32 .text
# As far as I know, these two R_386_32 relocations both indicate that the
# full, absolute address of these two locations should be inserted in
# these two locations.
$ bin/ld.lld test.o -o exe -e entry
$ bin/llvm-dwarfdump --eh-frame exe
exe:file format ELF32-i386
.debug_frame contents:
0010 CIE
0014 0018 FDE cie= pc=004010c0...004010c5
^
# The CIE offset, the third field, is set as zero (the offset where the
# CIE starts, even though the relocation indicated
Re: [lldb-dev] Inconsistencies in CIE pointer in FDEs in .debug_frame
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 field is interpreted as an offset from the current FDE - this seems to be consistent. But for cases in .debug_frame, they are treated differently. In LLDB, the cie_id field is assumed to be relative to the begin of the .debug_frame section: https://github.com/llvm/llvm-project/blob/master/lldb/source/Symbol/DWARFCallFrameInfo.cpp#L482-L495 However, when this field is produced in LLVM, it can, depending on MCAsmInfo flags, end up written as a plain absolute address to the CIE: https://github.com/llvm/llvm-project/blob/master/llvm/lib/MC/MCDwarf.cpp#L1699-L1705 That code in MCDwarf.cpp hasn't been touched in many years, so I would expect that the info it generates actually has been used since and been found to be correct. Or are most cases built with -funwind-tables or similar, enabled by default?, so this is exercised in untested cases? In the case where I'm running in this, LLDB reports "error: Invalid cie offset" when running executables with such .debug_frame sections. By adding an ", true" to the end of the EmitSymbolValue call in MCDwarf.cpp, the symbol reference is made section relative and the code seems to do what LLDB expects. Is that correct, or should LLDB learn the cases (which?) where the cie_id is an absolute address instead of a section relative one? // Martin What's the target you're encountering this behavior on? Can you maybe provide a short example of how the CIE/FDE entries in question look like? I could be wrong (I'm not really an expert on this), but my understanding is that "asmInfo->doesDwarfUseRelocationsAcrossSections()" is basically equivalent to "is target MachO", and the reason that we don't emit section relative addresses there is because MachO does not link debug info sections. This means there will only ever be a single debug_frame contribution in one file, and so we can just put offsets directly, instead of relying on linker to patch things up. Doing anything like this in a format which links (concatenates) debug info sections would certainly result in irreparably corrupted unwind info, since you have no idea what will be present at a certain absolute address (offset) once the linker has finished its thing. That said, if that is all there is here, then it does not seem to me like there's any special support in lldb needed, as the cie offset will always be a correct absolute offset from the start of the section by the time lldb gets to see it (and so it shouldn't matter if the offset was put there by the compiler or the linker). This makes me think that I am missing something, but I have no idea what could that be.. Anyway, I hope this helps somehow.. pl ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
