Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CoreCommands,PackageModel: introduce -debug-format option #6659

Merged
merged 1 commit into from Jun 21, 2023

Conversation

compnerd
Copy link
Collaborator

@compnerd compnerd commented Jun 20, 2023

This adds a new flag -debug-format that allows some structured control over the debug information format. This is particularly important for Windows where there are two different debugging information formats:

  • Code View (PDB)
  • DWARF

While theoretically LLDB supports PDBs, the overall support for that is limited. Furthermore, the CodeView emitted by the swift frontend is limiting for debugging as expression evaluation as not possible due to the debug information encoding employed by Swift: skeletal information is emitted into the binary and the type information is queried dynamically by the AST deserialiser in the compiler.

DWARF on the other hand does not support PE/COFF particularly well (e.g. exceeding the section name limits, representations potentially not being serialisable into the object file, etc), but allows a better experience with LLDB. More importantly, it breaks debugging with the system libraries (e.g. kernel32 or NTDLL). As a result, while it is often used with Swift code, PDBs can also be beneficial. Furthermore, DWARF forces the use of lld as the linker as link does not properly emit linked DWARF information.

Provide a top-level control to emit the debug information in a particular format as both of these options require altering the C/C++, Swift, and linker flags. We default to DWARF on all platforms, but on Windows, if CodeView is selected, we will alter the flags appropriately to ease switching of debug information format.

@compnerd compnerd force-pushed the debug-info branch 3 times, most recently from 9cc8869 to 37209fb Compare June 21, 2023 12:41
This adds a new flag `-debug-format` that allows some structured control
over the debug information format.  This is particularly important for
Windows where there are two different debugging information formats:
  - Code View (PDB)
  - DWARF

While theoretically LLDB supports PDBs, the overall support for that is
limited.  Furthermore, the CodeView emitted by the swift frontend is
limiting for debugging as expression evaluation as not possible due to
the debug information encoding employed by Swift: skeletal information
is emitted into the binary and the type information is queried
dynamically by the AST deserialiser in the compiler.

DWARF on the other hand does not support PE/COFF particularly well (e.g.
exceeding the section name limits, representations potentially not being
serialisable into the object file, etc), but allows a better experience
with LLDB.  More importantly, it breaks debugging with the system
libraries (e.g. kernel32 or NTDLL). As a result, while it is often used
with Swift code, PDBs can also be beneficial.  Furthermore, DWARF forces
the use of lld as the linker as link does not properly emit linked DWARF
information.

Provide a top-level control to emit the debug information in a
particular format as both of these options require altering the C/C++,
Swift, and linker flags.  We default to DWARF on all platforms, but on
Windows, if CodeView is selected, we will alter the flags appropriately
to ease switching of debug information format.
@compnerd compnerd marked this pull request as ready for review June 21, 2023 13:30
@compnerd
Copy link
Collaborator Author

@swift-ci please smoke test

@compnerd compnerd merged commit 383fa10 into apple:main Jun 21, 2023
5 checks passed
@compnerd compnerd deleted the debug-info branch June 21, 2023 17:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants