<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">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">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>