DWARF without DSYM

Dmitry_Shevchenko · August 25, 2016, 8:10pm

Can swiftc generate debug info without a separate dSYM bundle? -g option
looks to always generate a dSYM.

jrose · August 25, 2016, 8:15pm

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

Dmitry_Shevchenko · August 26, 2016, 4:36pm

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

jrose · August 26, 2016, 6:37pm

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@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@apple.com <mailto:jordan_rose@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 <mailto: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 <mailto:swift-users@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-users

Jim_Ingham · August 26, 2016, 7:36pm

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 <dmishe@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@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

Dmitry_Shevchenko · August 26, 2016, 9:35pm

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@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 <dmishe@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@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

Dmitry_Shevchenko · August 26, 2016, 9:43pm

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@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@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 <dmishe@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@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

Jim_Ingham · August 26, 2016, 9:49pm

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@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@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@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 <dmishe@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@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

Dmitry_Shevchenko · September 1, 2016, 9:04pm

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 -

github.com

apple/swift-lldb/blob/d4114d1eb749963f81ee7e6f937e1ee27681381d/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.cpp#L1602


      
          
          DataBufferSP
          SymbolFileDWARFDebugMap::GetASTData (lldb::LanguageType language)
          {
              if (language == eLanguageTypeSwift)
              {
                  Symtab* symtab = m_obj_file->GetSymtab();
                  if (symtab)
                  {
                      uint32_t start_idx = 0;
                      Symbol *symbol = symtab->FindSymbolWithType (eSymbolTypeASTFile,
                                                                   Symtab::eDebugAny,
                                                                   Symtab::eVisibilityAny,
                                                                   start_idx);
                      if (symbol)
                      {
                          FileSpec file_spec(symbol->GetName().GetCString(), false);
                          if (file_spec.Exists())
                              return file_spec.ReadFileContents();
                      }
                  }

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@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@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@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@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 <dmishe@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@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
>

Dmitry_Shevchenko · September 6, 2016, 6:01pm

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 that point on LLDB seems to be able to follow imports.

However, suppose we have a program that consists of two Objective-C
libraries, that also have some parts of them written in Swift.

Say libFoo and libBar. Both contain some amount of Swift code, that is
confined to internals of those libraries.

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.

But there isn't really a "main" module in this scenario. Should one be
synthesized somehow? Is this use case not yet supported?

···

On Thu, Sep 1, 2016 at 5:04 PM Dmitry Shevchenko <dmishe@google.com> wrote:

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@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@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@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@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 <dmishe@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@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
>

Topic		Replies	Views
Compiling via bitcode with debugging symbols Compiler	1	1142	May 11, 2018
[GSoC 2019] Swift debugging support on Linux LLDB gsoc-2019	5	1117	April 3, 2019
About Swift Package Manager and LLDB Using Swift	7	904	November 6, 2017
[Pitch] Include lldb-dap in Swift toolchain LLDB vscode	6	1327	April 11, 2024
Modifying debug info for hermetic/distributable builds Compiler	5	2146	June 8, 2018

DWARF without DSYM

Related Topics