[swift-users] DWARF without DSYM

Dmitry Shevchenko dmishe at google.com
Thu Sep 1 16:04:53 CDT 2016


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 <jingham at 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 <dmishe at 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 <dmishe at 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 <jingham at 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 at 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 <dmishe at 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_rose at 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 at 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 at swift.org
> > >> > https://lists.swift.org/mailman/listinfo/swift-users
> > >>
> > >
> > > _______________________________________________
> > > swift-users mailing list
> > > swift-users at swift.org
> > > https://lists.swift.org/mailman/listinfo/swift-users
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-users/attachments/20160901/2c72ebc8/attachment.html>


More information about the swift-users mailing list