[SR-2637] Issue with debugging programs that contain multiple Swift modules

[swift-ci]

Previous ID	SR-2637
Radar	None
Original Reporter	dmishe (JIRA User)
Type	Bug
Status	Closed
Resolution	Done

Attachment: Download

Environment

Apple Swift version 3.0 (swiftlang-800.0.46.2 clang-800.0.38)
Target: x86_64-apple-macosx10.9

Additional Detail from JIRA

Votes	0
Component/s	LLDB for Swift
Labels	Bug
Assignee	@trfiala
Priority	Medium

md5: b76ab4f38b9543ef86bb7f211e8dd45d

cloned to:

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

Issue Description:

Suppose we have an Objective-C program that uses two Swift modules. We would like to debug this program with LLDB without having a dSYM for faster builds.

                         ┌───────┐
                      ┌──│ Swift │
┌───────┐   ┌───────┐ │  └───────┘
│  Bin  │◀──│ ObjC  │◀┤           
└───────┘   └───────┘ │  ┌───────┐
                      └──│ Swift │
                         └───────┘

Each Swift module consist of a .swiftmodule, .o, and the .h header.

swiftc -c -g src/foo.swift \
  -module-name Foo \
  -emit-module-path out/Foo.swiftmodule \
  -emit-objc-header-path out/Foo-Swift.h \
  ...

We then link the two Swift objects and Objective-C objects into the final binary. It looks like LLDB needs to have .swiftmodule information for debugging, so we include references as AST entries.

clang src/main.m -fobjc-arc -o out/main out/foo.o out/bar.o \
  -Xlinker -add_ast_path -Xlinker out/Foo.swiftmodule \
  -Xlinker -add_ast_path -Xlinker out/Bar.swiftmodule
  ...

When we run LLDB on this binary and set breakpoints inside of the code for Foo and Bar modules, only the Foo types are picked up by LLDB. It only reads the first AST reference, ignoring others. If we swap the order of add_ast_path options we get symbols from the other module.

The full build is in attached zip file. Unpack and run build.sh. In its output, you will see that frame variable self command only correctly prints the variable for one module, not both.

[trfiala]

Thanks for giving us more detail here, Dmitry!

I'll track down somebody to expand on options here.

[trfiala]

HI Dmitry,

I've poked around with a few people over here. The first question is around manually calling clang to do the linking:

Q. Is the only reason that you're calling clang directly to link so that you can avoid getting a dsym built? If so, we have a few options here, which I discussed with @belkadan and @DougGregor:

1. Modify swiftc linking to avoid calling dsymutil if linking without the -g flag when on Apple OSes. This would then mirror the way clang linkage currently works.

2. Add a swiftc flag to explicitly disable dsymutil from being called. This would not match clang, but isn't necessarily a bad option.

3. Add a swiftc mode that just gathers linker flags, so that another linker (such as clang or ld) can link a swift binary properly.

Jordan is willing to make changes to support one or more of the above.

One avenue to investigate, and which the above might correct if this is the issue, is whether the -add_ast_path settings are correct. You can run swiftc in a mode where it dumps out the command lines it generates when calling other tools under the covers. To get that behavior, add '-###' (dash pound pound pound) to the swiftc command line. If you do that, you could validate what flags swiftc would have used to link, and ensure yours are matching.

Based on what you are seeing, I suspect we may also have an issue that could be addressed on the LLDB side, and quite possibly because you're generating binaries in a way that exposes a latent issue that we don't normally hit with standard swift linkage (and a call to dsymutil).

If you can try out the swiftc -### and figure out what it would have done for flags, and verify the ones you are using on the clang linkage line match, that would be a good first step to diagnosing.

Thanks!

[belkadan]

To be clear, we already do (1); it's just that it would require two invocations of swiftc. But if you're using Clang to link you're effectively doing that anyway.

[trfiala]

(Oops, thanks for correcting, Jordan!)

[belkadan]

Whether or not you can have multiple -add_ast_paths in one file is an LLDB-side issue. Static linking isn't really supported, so it hasn't come up.

[trfiala]

Greg Clayton, @belkadan and I discussed this a bit. We know we're likely to support static linking anyway, so we're going to take a crack at handling this. We see that the linked file has the multiple ast paths in it. We need to loop over them and feed them to the ast context that we build up internally.

I'm going to have a look and see if I can get that working in the GitHub master-next branches. (That would be swift/master-next, swift-lldb/master-next, swift-llvm/stable-next and swift-clang/stable-next branches).

[trfiala]

(Dmitry, if this gets quite involved, I may need to pass this off to you to try to implement).

[swift-ci]

Comment by Dmitry Shevchenko (JIRA)

That sounds great!

Could you clarify the state of the static linking support? It seems possible to link with the stdlib statically, and SPM links packages statically (not the runtime though), so what is really missing?

Using swiftc to link, with -g, it tries to merge the modules provided into "main" module, and fails:

$ swiftc out/foo.o out/bar.o  out/main.o  out/Foo.swiftmodule out/Bar.swiftmodule  -g
<unknown>:0: error: cannot load module 'Foo' as 'main'
<unknown>:0: error: merge-module command failed with exit code 1 (use -v to see invocation)

[swift-ci]

Comment by Dmitry Shevchenko (JIRA)

Todd, and just to clarify, there's no work around we can try in the meantime, we should look into whether this works with dSYM?

[belkadan]

Static linking works in limited circumstances, including building a single command-line tool with no non-system dependencies. In other cases (including the package manager), I think we're squeaking by with regards to debugging, or possibly just leaving things on the floor. "It compiles but debugging is utterly broken" doesn't really count as supported. (cc @ddunbar)

I'm sorry, I forgot that swiftc will try to merge modules given to it. That could still be useful if -c didn't also merge modules, so I don't know if it makes sense to change that behavior. (The suggestion was to link without -g, though.)

[swift-ci]

Comment by Dmitry Shevchenko (JIRA)

Oh I misunderstood, linking without -g does not allow me to even specify a swiftmodule input at all. It does not record anything in AST and predictably debugger fails to figure out types.

After more experimentation, I found out that to make this work well I need both dSYM generation and both AST records. After linking, the dSYM product contains a __swift_ast section of size equal to two .swiftmodules. LLDB then is able to parse both through the magic of Swift's ASTSectionImporter, neat 🙂 I suppose that means that there's no reason LLDB can't read multiple AST refs in the first place.

[trfiala]

> Oh I misunderstood, linking without -g does not allow me to even specify a swiftmodule input at all.

Hmm, @belkadan, I thought we saw differently when we looked at the code this morning?

> After more experimentation, I found out that to make this work well I need both dSYM generation and both AST records.

dmishe (JIRA User), I would expect that you would need both AST records. If you ran swiftc with the -### option and looked at the link step, I think that would show up there.

The piece I'm looking at is to see if we can find and feed all the ASTs we find into our AST Context. There's a chance we'll wire this up on the LLDB side and still need a bit of help from Jordan, et al. But I should know soon enough. (I got stuck on a couple hot potatoes today so I'm going to have to tackle this in the morning). I'm looking to change our SymbolFile AST retrieval method to return a vector of AST data blobs instead of just one, and then loop around and feed them all into the ingestion process in SwiftASTContext. I'll then see what happens from there.

If this does work, I need to really do this via a change to LLVM.org LLDB, pull that through, and make the Swift LLDB change on top of that.

I'll keep you posted!

[swift-ci]

Comment by Dmitry Shevchenko (JIRA)

When I have one module, yes, -add_ast_path shows up in swiftc link step when invoked with -g. But I can't really figure out how to make it link 2 modules into a binary without merging them. With -g it tries to merge swiftmodule inputs as I mentioned, and without -g it does not care about modules at all.

I can manually construct the link step using clang -g -add_ast_path Foo.swiftmodule -add_ast_path Bar.swiftmodule and then both modules will be written into dSYM DWARF segment.

[trfiala]

With the binaries you attached, Greg Clayton and I were able to see all the ast path info we needed I thought. So your initial usage scenario is what I'm hoping to get working on the LLDB side (with the caveat that it might incur a required change on the Swift side, we'll know soonish).

[swift-ci]

Comment by Dmitry Shevchenko (JIRA)

Just to clarify, this is what I mean by saying that swiftc won't accept swiftmodules without -g:

$ swiftc out/foo.o out/bar.o out/main.o out/Foo.swiftmodule out/Bar.swiftmodule 
<unknown>:0: error: unexpected input file: out/Foo.swiftmodule
<unknown>:0: error: unexpected input file: out/Bar.swiftmodule