Skip to content

Add support for uploading symbols to a public symbol server #1064

Merged
mhegazy merged 6 commits intocompnerd:mainfrom
mhegazy:upstream-symserver-2
Jan 20, 2026
Merged

Add support for uploading symbols to a public symbol server #1064
mhegazy merged 6 commits intocompnerd:mainfrom
mhegazy:upstream-symserver-2

Conversation

@mhegazy
Copy link
Collaborator

@mhegazy mhegazy commented Jan 2, 2026

This change adds support to uploading symbols to a public symbol server hosted on R2. To get access to the symbols, you need to add the public swift-toolchain to your sym path _NT_SYMBOL_PATH or simply add it windbg while debugging:

.sympath+ SRV*https://swift-toolchain.thebrowserco.com/symbols

Details:

We are using Symstore.exe to prepare the symbols and manage their state. This tool is ment to be used on a single build machine or with a network share. Since we are using R2, and R2/S3 do not implement locking guarantees this opens us up to concurrent access to the store. The good news is that there is little chance of symbols collision since they are stored under a hash of the pdb file, but there are 3 text files that symstore.exe uses to record state of the symbols. these files are used to enable pruning symbols from the server when needed.

The implementation here uses an optimistic concurrency model where each worker will attempt to grab the latest state and then update it. We use the S3/R2 atomic operation if-match to ensure that no state change happened in between, if so we also upload the symbols, if not we retry.

The process of preparing the symbols is rather short, this whole action adds 2-3 minutes for each build job, including the installation of the tools, and the actual upload.

Downstream runs:

https://github.com/thebrowsercompany/swift-build/actions/runs/21041733569

Copy link
Owner

@compnerd compnerd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need to upload the symbols to both the public and private copies of the PDBs? Why not only retain the public (R2) and consider decommissioning the Azure storage?

@mhegazy
Copy link
Collaborator Author

mhegazy commented Jan 5, 2026

Do we need to upload the symbols to both the public and private copies of the PDBs? Why not only retain the public (R2) and consider decommissioning the Azure storage?

Not really. wanted to get some milage on this first, then we can switch.

@mhegazy mhegazy requested a review from Steelskin January 5, 2026 17:22
@mhegazy mhegazy force-pushed the upstream-symserver-2 branch from b104708 to ecc03df Compare January 15, 2026 18:17
@mhegazy
Copy link
Collaborator Author

mhegazy commented Jan 15, 2026

@Steelskin and @compnerd can i get another look.

I also have an updated passing run in https://github.com/thebrowsercompany/swift-build/actions/runs/21041733569

@mhegazy mhegazy requested review from Steelskin and compnerd January 15, 2026 22:35
@mhegazy mhegazy merged commit 6023463 into compnerd:main Jan 20, 2026
mhegazy added a commit to mhegazy/swift-build that referenced this pull request Jan 31, 2026
…#1064)

* Add support for uploading symbols to a public symbol server

* Adjust sleep time

* Only run in releases

* Add comment about version used

* Revert "Only run in releases"

This reverts commit 465b421.

* Remove unused variables
mhegazy added a commit that referenced this pull request Feb 1, 2026
…1083)

* Add support for uploading symbols to a public symbol server

* Adjust sleep time

* Only run in releases

* Add comment about version used

* Revert "Only run in releases"

This reverts commit 465b421.

* Remove unused variables
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.

3 participants