<div dir="ltr">Reading more about Swift modules under swift/docs. I start to believe that there's always one "main" swift module per executable, is that right?<div><br></div><div>In that case, a pure Swift program poses no issues with debugging, there's always an "entry point" Swift module that can be specified in N_AST and from that point on LLDB seems to be able to follow imports.</div><div><br></div><div>However, suppose we have a program that consists of two Objective-C libraries, that also have some parts of them written in Swift.</div><div><br></div><div>Say libFoo and libBar. Both contain some amount of Swift code, that is confined to internals of those libraries.</div><div><br></div><div>In the end we link libFoo.a and libBar.a into the executable, and at this point we have a chance to add an AST reference to swiftmodule to aid debugging.</div><div><br></div><div>But there isn't really a "main" module in this scenario. Should one be synthesized somehow? Is this use case not yet supported?</div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Sep 1, 2016 at 5:04 PM Dmitry Shevchenko <<a href="mailto:dmishe@google.com">dmishe@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi all, thanks for all the pointers.<div><br></div><div>After some more research, I have found that without dSYM, Xcode uses -add_ast_path to encode swiftmodule location.</div><div><br></div><div>It then seems like you can only have one AST tag per binary, or at least only the first one is checked - <a href="https://github.com/apple/swift-lldb/blob/d4114d1eb749963f81ee7e6f937e1ee27681381d/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.cpp#L1602" target="_blank">https://github.com/apple/swift-lldb/blob/d4114d1eb749963f81ee7e6f937e1ee27681381d/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.cpp#L1602</a></div><div><br></div><div>What if a program is composed from multiple Swift modules, say A imports B which imports C, we then have 3 swiftmodule files. Which one should be referenced during the linking step, A? Undefined behavior? :)</div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Aug 26, 2016 at 5:50 PM Jim Ingham <<a href="mailto:jingham@apple.com" target="_blank">jingham@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">In any case where the .o files are temporary objects which the driver will delete when it's done, it has to generate a dSYM file before it deletes them. But if the .o files belong to the user it can assume it's okay to hold off on generating the dSYM. Same thing happens with the clang driver.<br>
<br>
Jim<br>
<br>
> On Aug 26, 2016, at 2:43 PM, Dmitry Shevchenko <<a href="mailto:dmishe@google.com" target="_blank">dmishe@google.com</a>> wrote:<br>
><br>
> Ah I see, the dsym job is only created when the driver will also link the final product, in Xcode build case, it separates the linking step.<br>
><br>
> On Fri, Aug 26, 2016 at 5:35 PM Dmitry Shevchenko <<a href="mailto:dmishe@google.com" target="_blank">dmishe@google.com</a>> wrote:<br>
> I experimented in Xcode, and with DWARF w/o dSYM selected, debugging still works. And even though -g option is passed to swiftc, there's no dSYM generation occurring. So besides -g, what else makes swiftc issues that dsymutil call?<br>
><br>
> On Fri, Aug 26, 2016 at 3:37 PM Jim Ingham <<a href="mailto:jingham@apple.com" target="_blank">jingham@apple.com</a>> wrote:<br>
> dsymutil is only given the .o files and the executable - same thing lldb sees. So if it can find the module map to copy it into the dSYM, lldb can find it and load it without the dSYM. So whether it does work or not, it should be able to.<br>
><br>
> Jim<br>
><br>
> > On Aug 26, 2016, at 11:37 AM, Jordan Rose via swift-users <<a href="mailto:swift-users@swift.org" target="_blank">swift-users@swift.org</a>> wrote:<br>
> ><br>
> > I suppose it can, but in theory the module that goes into the dSYM wouldn't be the same as the one that gets used by clients of a library. (Example: the one in the dSYM needs to have info about private types.) Sean can probably explain better than I can.<br>
> ><br>
> > Jordan<br>
> ><br>
> ><br>
> >> On Aug 26, 2016, at 9:36, Dmitry Shevchenko <<a href="mailto:dmishe@google.com" target="_blank">dmishe@google.com</a>> wrote:<br>
> >><br>
> >> I see. I thought LLDB can import modules independently of sources, isn't that what target.swift-module-search-paths option is for?<br>
> >><br>
> >> On Thu, Aug 25, 2016 at 4:15 PM Jordan Rose <<a href="mailto:jordan_rose@apple.com" target="_blank">jordan_rose@apple.com</a>> wrote:<br>
> >> Plain DWARF isn't sufficient to debug a Swift program (we actually stuff the entire swiftmodule into the dSYM), but if you just want to trace execution you should be able to use -gline-tables-only.<br>
> >><br>
> >> Jordan<br>
> >><br>
> >><br>
> >> > On Aug 25, 2016, at 13:10, Dmitry Shevchenko via swift-users <<a href="mailto:swift-users@swift.org" target="_blank">swift-users@swift.org</a>> wrote:<br>
> >> ><br>
> >> > Can swiftc generate debug info without a separate dSYM bundle? -g option looks to always generate a dSYM.<br>
> >> > _______________________________________________<br>
> >> > swift-users mailing list<br>
> >> > <a href="mailto:swift-users@swift.org" target="_blank">swift-users@swift.org</a><br>
> >> > <a href="https://lists.swift.org/mailman/listinfo/swift-users" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-users</a><br>
> >><br>
> ><br>
> > _______________________________________________<br>
> > swift-users mailing list<br>
> > <a href="mailto:swift-users@swift.org" target="_blank">swift-users@swift.org</a><br>
> > <a href="https://lists.swift.org/mailman/listinfo/swift-users" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-users</a><br>
><br>
<br>
</blockquote></div></blockquote></div>