Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[SR-13066] LLDB does not descend into system libraries when debugging #4463

swift-ci opened this issue Jun 24, 2020 · 1 comment

[SR-13066] LLDB does not descend into system libraries when debugging #4463

swift-ci opened this issue Jun 24, 2020 · 1 comment
bug LLDB for Swift


Copy link

@swift-ci swift-ci commented Jun 24, 2020

Previous ID SR-13066
Radar None
Original Reporter ryanw (JIRA User)
Type Bug
Status Closed
Resolution Won't Do

Fedora 32 with master build:
Swift version 5.3-dev (LLVM 94a8a8d0ffb5977, Swift ec8d5f4ecbe53e6)
Target: x86_64-unknown-linux-gnu

Additional Detail from JIRA
Votes 0
Component/s LLDB for Swift
Labels Bug
Assignee None
Priority Medium

md5: 85f44c70950f94d14109f17737a772fa

Issue Description:

I am working on a command line app on Linux (Fedora 32). I am trying to use the sd-bus API from systemd, however am having some issues using the API.

While trying to debug, I have found that LLDB will not step into the sd-bus functions I am calling, even though I have the relevant -debug-info and -debug-source packages installed.

I have also installed the LZMA dev packages and manually enabled LLDB's support for LZMA-compressed debug info in the swift build script.

I do note the following warning from LLDB when starting execution:

warning: (x86_64) /lib64/ unsupported DW_FORM values: 0x1f20 0x1f21

I am able to use step-inst to descend into the functions, however no usable symbol info is available.

Example LLDB output:

Process 509983 stopped
* thread #​1, name = 'Tsunami', stop reason = instruction step into
    frame #​0: 0x00007ffff6fb2f22`sd_bus_call + 18`sd_bus_call:
->  0x7ffff6fb2f22 <+18>: pushq  %rbp
    0x7ffff6fb2f23 <+19>: movq   %rdi, %rbp
    0x7ffff6fb2f26 <+22>: movq   %rsi, %rdi
    0x7ffff6fb2f29 <+25>: pushq  %rbx
Target 0: (Tsunami) stopped.

GDB output showing expected symbols:

0x00005555556a8ce7  173         r = sd_bus_call(bus, m, 0, &error, reply)
(gdb) s
sd_bus_call (bus=0x55555586cb50, _m=0x55555586dbb0, usec=0, error=0x7fffffffd3f0,
    reply=0x7fffffffd408) at ../src/libsystemd/sd-bus/sd-bus.c:2147
2147                    sd_bus_message **reply) {
2149            _cleanup_(sd_bus_message_unrefp) sd_bus_message *m = sd_bus_message_ref(_m);
sd_bus_message_ref (m=0x55555586dbb0) at ../src/libsystemd/sd-bus/bus-message.c:911
911 _public_ sd_bus_message* sd_bus_message_ref(sd_bus_message *m) {
912         if (!m)

I note a number of patches for LLDB in 2019 to add LZMA and .gnu-debug-data support, but I would assume these have been integrated into LLDB 10.0 which Swift 5.3 seems to be using.

Copy link

@swift-ci swift-ci commented Sep 25, 2020

Comment by Ryan (JIRA)

Turns out this is due to Fedora's use of DWZ compression for it's debug symbols, which is not supported by LLDB.

It looks like there is a proposal to drop this in favour of -fdebug-types-section for Fedora 34 ( so I doubt the existing DWZ patches for LLDB will be upstreamed. Closing this.

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
@shahmishal shahmishal transferred this issue from apple/swift May 7, 2022
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
bug LLDB for Swift
None yet

No branches or pull requests

1 participant