Hi all, thanks for all the pointers. After some more research, I have found that without dSYM, Xcode uses -add_ast_path to encode swiftmodule location.
It then seems like you can only have one AST tag per binary, or at least only the first one is checked - https://github.com/apple/swift-lldb/blob/d4114d1eb749963f81ee7e6f937e1ee27681381d/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.cpp#L1602 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? :) On Fri, Aug 26, 2016 at 5:50 PM Jim Ingham <jing...@apple.com> wrote: > 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. > > Jim > > > On Aug 26, 2016, at 2:43 PM, Dmitry Shevchenko <dmi...@google.com> > wrote: > > > > 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. > > > > On Fri, Aug 26, 2016 at 5:35 PM Dmitry Shevchenko <dmi...@google.com> > wrote: > > 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? > > > > On Fri, Aug 26, 2016 at 3:37 PM Jim Ingham <jing...@apple.com> wrote: > > 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. > > > > Jim > > > > > On Aug 26, 2016, at 11:37 AM, Jordan Rose via swift-users < > swift-users@swift.org> wrote: > > > > > > 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. > > > > > > Jordan > > > > > > > > >> On Aug 26, 2016, at 9:36, Dmitry Shevchenko <dmi...@google.com> > wrote: > > >> > > >> I see. I thought LLDB can import modules independently of sources, > isn't that what target.swift-module-search-paths option is for? > > >> > > >> On Thu, Aug 25, 2016 at 4:15 PM Jordan Rose <jordan_r...@apple.com> > wrote: > > >> 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. > > >> > > >> Jordan > > >> > > >> > > >> > On Aug 25, 2016, at 13:10, Dmitry Shevchenko via swift-users < > swift-users@swift.org> wrote: > > >> > > > >> > Can swiftc generate debug info without a separate dSYM bundle? -g > option looks to always generate a dSYM. > > >> > _______________________________________________ > > >> > swift-users mailing list > > >> > swift-users@swift.org > > >> > https://lists.swift.org/mailman/listinfo/swift-users > > >> > > > > > > _______________________________________________ > > > swift-users mailing list > > > swift-users@swift.org > > > https://lists.swift.org/mailman/listinfo/swift-users > > > >
_______________________________________________ swift-users mailing list swift-users@swift.org https://lists.swift.org/mailman/listinfo/swift-users
