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?
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 t
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
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.
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 wrote:
> I experimented in Xcode, and with DWARF w/o dSYM selected, debugging still
> works. And even tho
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 wrote:
> dsymutil is
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, Dmi
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 sw
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 wrote:
> Plain DWARF isn't sufficient to debug a Swift program (we actually stuff
> the entire swiftmodule into the dSYM)
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
> wrote:
>
> Can swiftc
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
10 matches
Mail list logo
