UR-11: publish build identity and a symbol map
Keep the build_id section and the assert strings, and publish the function name map that the build already produces. No runtime change, and it saves hours per client update.
This request doesn't correct a defect. It asks ArenaNet to keep three things the build already produces, and to publish one of them. Two of the three items are "change nothing"; the third is publishing an artifact that already exists.
Fix: low effort, no blast radius at runtime — the published module doesn't change, only the set of published files grows.
The problem this solves
The published module is stripped: about 17,600 functions, no names, each one identified only by its index. Every recompile moves those indices — add one function and every index after it changes. Static data addresses move too, and not by one common offset; we measured this on build 38797, and the addresses share no single delta.
Any host that needs to locate something inside the client repeats that work after every update. For us it's the single largest cost of the project.
What we ask for
Keep the build_id custom section
The module carries a custom section with a build identifier. We use it to gate every build-specific decision, and we refuse to run any transform on an unknown build.
Keep the assert strings and the source paths
The data section holds assert messages and original source paths, for example
p:\code\gw\ui\game\party\ptsearch.cpp. They come from the source, not the
compiler, so they survive recompiles that move every index. They're the most
stable anchors in the binary — the Windows tool community has leaned on them
for twenty years.
Publish the function name map
The build already produces a name map: the module references
external_debug_info, and an earlier build shipped with names. Publishing
that map as a separate file per build solves the problem outright.
The name map, in detail
A name map turns our hardest problem into a table lookup.
We already carry names forward between builds with a correlator that compares an older named build against the new stripped one, using nine heuristics. On one build pair it mapped 17,302 of 17,739 functions automatically, left 433 uncertain, and 4 unmapped. That's a good result — and still a guess. A published map makes it exact.
Acceptable forms
We don't need full debug information. Any of these works:
| Form | Content | Our result |
|---|---|---|
| A full name section | Index to name for every function | Exact |
| A partial map | Index to name for exported and asserted functions only | Almost exact |
| A hash map | Index to a stable hash of the mangled name | Exact matching, no readable names |
The third form discloses the least and still solves the problem — we only need to know that function 2469 in the new build is the same function as 2461 in the old one.
What we don't ask for
No source code, no private build-system symbols, no debug build.
A fourth, optional item: announce a build
We poll the patch manifest every fifteen minutes to notice a new build. That's polite, but wasteful for both sides. A field in the manifest, or a small feed, would let us react to a signal instead of a timer. Optional — the polling works, and we keep it under one request per quarter hour.
Acceptance criteria
- The
build_idcustom section is present in the published module. - The assert strings and the source paths stay in the data section.
- A name map, in one of the three forms above, is published with each build, at a stable URL.
- The map covers the functions in the code section of the same build.