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-3280] Package manager should link main swiftmodule in executables #5164

Closed
swift-ci opened this issue Nov 27, 2016 · 12 comments
Closed

[SR-3280] Package manager should link main swiftmodule in executables #5164

swift-ci opened this issue Nov 27, 2016 · 12 comments
Assignees
Labels

Comments

@swift-ci
Copy link
Contributor

@swift-ci swift-ci commented Nov 27, 2016

Previous ID SR-3280
Radar rdar://problem/29228963
Original Reporter nerakhon (JIRA User)
Type Bug
Status Resolved
Resolution Done
Additional Detail from JIRA
Votes 5
Component/s Package Manager
Labels Bug
Assignee @aciidb0mb3r
Priority Medium

md5: cd20a7b4bf80be0100567d8c27f63fe5

is blocked by:

  • SR-2660 Teach the driver to accept multiple swiftmodules as linker inputs, for static linking

is duplicated by:

  • SR-2192 Swift's LLDB cannot import system modules and prevents debugging
  • SR-11543 lldb doesn't work in tests: error: warning: failed to get module "NIO" from AST context

relates to:

  • SR-3863 swift emits a temporary swiftmodule when swiftmodule of main module is passed with -emit-executable
  • SR-11543 lldb doesn't work in tests: error: warning: failed to get module "NIO" from AST context

Issue Description:

Upon creation of empty packgage of type --executable when I build the package via swift build. I receive a binary that works, but isn't debuggable.

lldb .build/debug/lldb-test

(lldb) target create ".build/debug/lldb-test"
Current executable set to '.build/debug/lldb-test' (x86_64).
(lldb) breakpoint set -f main.swift -l 3
Breakpoint 1: where = lldb-test`main + 81 at main.swift:3, address = 0x0000000000400e81
(lldb) r
Process 30195 launched: '/home/janpaul/src/lldb-test/.build/debug/lldb-test' (x86_64)
Process 30195 stopped

  • thread #1: tid = 30195, 0x0000000000400e81 lldb-test`main + 81 at main.swift:3, name = 'lldb-test', stop reason = breakpoint 1.1
    frame #0: 0x0000000000400e81 lldb-test`main + 81 at main.swift:3
    1 import Foundation
    2
    -> 3 let swifty="Swift is cool"
    4
    5 print(swifty)
    6
    7 exit(0)
    (lldb) n
    Process 30195 stopped

  • thread #1: tid = 30195, 0x0000000000400ea4 lldb-test`main + 116 at main.swift:5, name = 'lldb-test', stop reason = step over
    frame #0: 0x0000000000400ea4 lldb-test`main + 116 at main.swift:5
    2
    3 let swifty="Swift is cool"
    4
    -> 5 print(swifty)
    6
    7 exit(0)
    (lldb) po swifty
    error: in auto-import:
    failed to get module 'lldb_test' from AST context

@swift-ci
Copy link
Contributor Author

@swift-ci swift-ci commented Nov 27, 2016

Comment by Jan Paul (JIRA)

The problem doesnt' exist when I build the main.swift manually via swiftc -g main.swift just in case there was doubt 😉

@aciidb0mb3r
Copy link
Member

@aciidb0mb3r aciidb0mb3r commented Nov 28, 2016

This looks like a problem with the compiler or lldb. lldb doesn't work when we use create executable via objects:

$ cat main.swift
let str = "Hello world"
print(str)

This works:
$ swiftc -g -o sample -emit-executable main.swift
$ lldb sample
(lldb) b main.swift:2
(lldb) r
(lldb) po str
"Hello world"

This doesn't:
$ swiftc -module-name sample -g -emit-object -c main.swift
$ swiftc -g -o sample -emit-executable main.o
$ lldb sample
(lldb) b main.swift:2
(lldb) r
(lldb) po str
error: in auto-import:
failed to get module 'sample' from AST context

--
$ swift --version
Swift version 3.0-dev (LLVM 8226908317, Clang e82f59cafd, Swift ce722fe0a5)
Target: x86_64-unknown-linux-gnu
$ lldb --version
lldb version 4.0.0 (git@github.com:apple/swift-lldb.git revision 85e9e3cafb8cd2c58e1197510f48ac13e92fbde3 clang revision e82f59cafd6c10e2063bc46b53f99b96d397371b llvm revision 822690831754af558dabf4048dd7da5ed2ff2f00)

Toolchain: swift-DEVELOPMENT-SNAPSHOT-2016-11-15-a-ubuntu16.04

@belkadan
Copy link

@belkadan belkadan commented Dec 9, 2016

That's correct. Swift needs to include the swiftmodule in the debug info, so if you link in a separate step it doesn't have a chance to do that. Take a look at what swiftc -### does.

@swift-ci
Copy link
Contributor Author

@swift-ci swift-ci commented Dec 10, 2016

Comment by Jin Mingling (JIRA)

this seem more critical because the SPM debug outcome can not be debugged.

do we have some workaround, such as some flag to let lldb(swift version) load swiftmodule info by manual?

@aciidb0mb3r
Copy link
Member

@aciidb0mb3r aciidb0mb3r commented Dec 16, 2016

@belkadan Thanks, looks like if you pass swiftmodule in link step (with module name) it debugs properly.
#856

@ddunbar
Copy link
Member

@ddunbar ddunbar commented Jan 23, 2017

This is fixed right?

@aciidb0mb3r
Copy link
Member

@aciidb0mb3r aciidb0mb3r commented Jan 23, 2017

Nope, see PR

@aciidb0mb3r
Copy link
Member

@aciidb0mb3r aciidb0mb3r commented Feb 9, 2017

#933

@aciidb0mb3r
Copy link
Member

@aciidb0mb3r aciidb0mb3r commented Feb 9, 2017

The problem is package manager need to link main swiftmodule with the executable to make them debuggable. The PR #933 on package manager is currently blocked by SR-3863 (duped by SR-2660).

It looks like the debugging works fine without linking swiftmodule if there is a search path to the system module package. So if you invoke swiftpm with it, debugging will work:
$ swift build -Xcc -I/path/to/system/module

or if you convert the system module to a "fake" Clang module, swiftpm will automatically add a search path. This is of course not the correct solution but maybe is useful in the mean time.

@weissi
Copy link
Member

@weissi weissi commented Oct 1, 2019

@aciidb0mb3r/@neonichu any updates on this? Apparently this is blocking all debugging on Linux and also partially on macOS.

@weissi
Copy link
Member

@weissi weissi commented Oct 1, 2019

@abertelrud
Copy link
Contributor

@abertelrud abertelrud commented Dec 1, 2020

I believe this is fixed in Swift 5.3. Comments in SR-11543 also suggest that this is fixed.

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

No branches or pull requests

6 participants