The next LLVM Project Council Meeting will take place on Wednesday, November 19 at 11am PDT / 8pm CET on meet.google.com/cyp-jxvf-kkb. This meeting is open for the public to observe, and participate upon request from the Project Council members. If you would like the Project Council to discuss a particular topic, please comment here or contact @project-council, e.g., by tagging us on Discourse threads.
Meeting notes Project Council Meetings - Google Docs . We discussed [RFC] Adding SFrame support to llvm and RFC: Require Pull Requests for all llvm-project commits and will follow-up on these RFCs.
1 Like
Thanks for sharing the notes 
I want to respectfully push back on the characterization that I am “insufficiently open to new contributions.” My role as maintainer is to be a technical steward for LLD’s long-term health, and the decisions referenced in the council notes reflect that responsibility.
Let me address the specific examples cited:
ICF safe mislinks objects with ADRP/LDR instructions split across sections, blocked PR from pranavk
Motivated folks reading through the discussion should note that I initially approved an earlier variant of the patch. It was landed and then reverted due to a new issue.
After further thought, I concluded that the relocation-based approach is not viable - it has significant arch-specific behavior and forward compatibility issues with new relocation types. In addition, the code doesn’t prove more robust. It seems to open a new can of issues.
Folks from Meta have been unable to upstream patches for Buck support, relocation overflow warnings, and other functionality over similar grounds of technical complexity.
The Buck support is supposed to be about ThinLTO linker options. We already have many ThinLTO options for build system integration. They work well, even if originally designed for Bazel, and about two years ago we got a refresh for tree artifacts.
Having too many linker options is distracting for users and other build systems. We should maintain our usual (high) standard for linker options.
I don’t think Buck support even has a formal proposal about what they need and how they design options to complement existing needs. For a successful example of this process, check out integrated distributed ThinLTO - it had an excellent plan and proposal. I have reviewed and approved many patches for that effort.
relocation overflow warnings
I’ve suggested --emit-relocs and post-processing as an alternative to linker reporting relocation overflow warnings.
I actually developed such a tool when I was at Google, only to find that someone in another part of Google had independently rewritten a similar tool.
As an analysis tool with a lot of nuances, it works better as a separate project from a linker.
To summarize: the pushback on these contributions was not about blocking contributors, but about fundamental technical concerns - incomplete solutions that would create ongoing maintenance burdens, architectural issues that would harm LLD’s design coherence, and narrow fixes that didn’t properly address underlying problems. In each case, I engaged with contributors to explain technical concerns and suggest more comprehensive approaches.
I strongly disagree with the framing that there is a “pattern of blocking contributions.” There is a pattern of maintaining technical standards - which is exactly what the project should expect from a maintainer.
Should we have a coherent project policy encouraging maintainers to unblock contributors, seek compromise, welcome niche contributions, or should we maintain high standards of excellence?
I would argue these are not mutually exclusive, but when they conflict, standards must come first.
Yes, LLVM is intended to be shared, open infrastructure, and yes, we should seek to grow the project. But sustainability over the long term requires maintaining a maintainable codebase. Accepting every contribution that increases complexity or creates technical debt is not sustainable, even if contributors are willing to maintain their additions over time (and in practice, that commitment often doesn’t materialize).
I am committed to being open to contributions that meet appropriate technical standards. I am committed to working with contributors to help them understand those standards and refine their approaches. But I cannot commit to lowering the technical bar for LLD in the name of “openness,” as that would be failing in my responsibility as maintainer.
I know arguments on paper can look subjective. I want to be clear that I try my best to maintain consistent technical standards regardless of the affiliation of the patch submitter. I welcome further discussion about where the appropriate balance lies, but I wanted to ensure my perspective as maintainer is clearly understood.
SFrame Discussion
SFrame is a stack walking format proposed by Oracle and implemented in binutils. Let me address the technical and process concerns around this format.
Technical Reality
- Replacing frame pointers with a stack unwinding/walking format could improve performance.
- Ecosystem viability: Multiple top-10 perf contributors have raised objections to SFrame. SFrame doesn’t replace .eh_frame while being larger. Competing with both frame pointers and hardware features puts SFrame in a very niche position.
- Superior alternative exists: Active RFC for Compact Unwind Information ([RFC] Improving compact x86-64 compact unwind descriptors) addresses a superset of SFrame’s goals and could completely replace both SFrame and most .eh_frame needs for the entire ecosystem.
- Format instability: v3 is coming with major and breaking changes, and the upstreamed version is v2, which will be obsoleted next year or lead to complex merge behavior.
- Both formats require linker support. Supporting both is not sustainable long-term. We need to choose the architecturally sound path once, not implement multiple competing formats.
- Size overhead: In x86-64 clang builds, .sframe is 10% larger than .eh_frame+.eh_frame_hdr, yet cannot replace .eh_frame (required for C++ exceptions, debugging). https://maskray.me/blog/2025-10-26-stack-walking-space-and-time-trade-offs
- ELF specification violations: SFrame deviates from established ELF conventions. (Compact unwind info can be implemented as an .eh_frame extension, mitigating the issue.) https://maskray.me/blog/2025-09-28-remarks-on-sframe#object-file-format-design-issues
- Some frames cannot be described by SFrame. (For completeness, also not by compact unwind information, but there is DWARF CFI escape/fallback). Building llvm-project with
gccorclang -fno-integrated-as& Binutils will show many warnings.
Ironically, GNU ld --gc-sections is broken, related to the lack of attention on object file format issues.
Process and Governance Concerns
- The contributors appear committed to SFrame as a viable solution without fully considering existing alternatives, with a determination to upstream it.
- My concern is that potential organizational urgency is overriding the normal technical review process that would typically prevent upstreaming something that is architecturally flawed.
- I am concerned that Project Council involvement could be used to short-circuit the normal review process and override technical objections.
Path Forward
- Ecosystem validation: Require demonstrated adoption in Linux kernel, major distributions (excluding Oracle Linux), or mobile platforms before LLVM commitment.
- Post-processing tool: For urgent Google server needs (claimed ~1% x86-64 performance), implement a standalone .eh_frame → .sframe converter.
- Invest in proper solution: Redirect effort toward the Compact Unwind RFC, which solves the problem comprehensively for the entire ecosystem by actually replacing .eh_frame rather than adding to it.
- Incubation and graduation: If SFrame demonstrates stability and clear evidence as a viable alternative, particularly after Compact Unwind Information is evaluated, it might eventually justify the dedicated maintenance effort. However, given the architectural concerns outlined above, I remain skeptical.
Context on My Technical Evaluation
I was initially skeptical when I learned that SFrame only supports stack walking, not full unwinding (which is needed for C++ exceptions and debugging). This means it must compete with frame pointers and hardware features, putting it in a very niche position.
I then reported object file format issues: Remarks on SFrame | MaskRay
However, the format maintainer did not address these concerns and insisted on mandatory index building even for -r links (intended for kernel modules, though some kernel developers prefer the simpler ORC Unwinder to SFrame for vmlinux and kernel modules).
Later, I discovered a significant size issue. Years ago, I had heard claims that SFrame could achieve half the size of .eh_frame, but the reality proved quite different.
The numbers tell the story: in an x86-64 build of clang, SFrame V2’s per-function size is 60 bytes, while the average .eh_frame FDE is 52 bytes. For compact unwind info, it’s promising to keep per-function overhead below 20 bytes (12 bytes before page table compression in the best case). At this point, I don’t believe SFrame is a viable format for userspace.
I raised “Concerns about SFrame viability for userspace stack walking” on the Linux perf mailing list and provided further analysis: https://lore.kernel.org/linux-perf-users/CAN30aBEN_4Q1gAqh5=6OXXw4BvnmeV41RQCyjm1p1r07ki=FEw@mail.gmail.com/
I hope this context clarifies my technical reasoning and demonstrates that my concerns are grounded in careful analysis rather than an unwillingness to accept contributions. I remain committed to the integrated assembler, LLVM binary utilities, and LLD’s technical excellence and long-term sustainability.
4 Likes
A random note about why maintaining technical standards matters for LLD’s sustainability.
The second-system effect—where successors to small, elegant systems become over-engineered and bloated with features—manifests clearly in ELF linkers, which have been created multiple times. GNU gold was a recent example.
Modern linkers exhibit concentrated contributor activity. Using commit counts as an imperfect metric, we can observe that this pattern is not unique to LLD—mold and wild show similar dynamics:
git shortlog -sn -- gold
820 Ian Lance Taylor
429 Cary Coutant
300 Alan Modra
146 Doug Kwan
133 H.J. Lu
111 Nick Clifton
...
git shortlog -sn -- mold
7039 Rui Ueyama
63 Tatsuyuki Ishi
55 Christoph Erhardt
40 Martin Liska
30 Yang Liu
...
git shortlog -sn -- wild
911 David Lattimore
185 Martin Liska
84 Martin Liška
83 dependabot[bot]
79 Mateusz Mikuła
...
git shortlog -sn -- lld/ELF
1961 Rui Ueyama
1449 Fangrui Song
1357 Rafael Espindola
898 George Rimar
201 Simon Atanasyan
168 Davide Italiano
162 Peter Smith
160 Peter Collingbourne
100 Eugene Leviant
...
git shortlog -sn --since=2022-01-01 -- lld/ELF
523 Fangrui Song
30 Kazu Hirata
15 Daniil Kovalev
15 Jessica Clarke
13 Daniel Thornburgh
12 Zhaoxin Yang
11 Peter Smith
9 Paul Kirth
9 serge-sans-paille
8 Nico Weber
8 Peter Collingbourne
7 Craig Topper
...
LLD, as part of the monolithic LLVM project, faces a higher barrier to entry due to its build requirements.
By contrast, linkers like wild benefit from Rust being the latest coolest language, which makes it easier to attract contributors.
Linker is also a toolchain area that gets relatively little attention. Most people would prefer to work on the compiler part.
FWIW I think that having the project council available to adjudicate technical disagreements can be a positive thing. And having an escalation path is healthy. For that to work, it has to be possible for the council to “override” a decision (i.e. come to a different conclusion after analysing the information, talking to the interested parties etc).
But reading the notes summary, I think although it’s very time consuming for the council to fill that role of adjudicating the technical disagreement properly it would need some subset of it to actually go through the discussion in detail, form their own view, potentially talk to those involved. Perhaps my expectation of how the council can help with such technical disagreements is unrealistic or unachievable?
This isn’t a particularly strongly held view, but I do think that it would be better resolve this disagreement and then encourage / help the establishment of an area team rather than to set up the area team in the hope of resolving it. Setting up new decision making structures with an active disagreement in the background (that the body would be expected to resolve) feels like it could make that process more fraught than necessary.
1 Like
Is it possible there has been some accidental edits to the notes? I just tried to take a look just now, but the November 19, 2025 notes don’t appear to be in English?
Looks like anyone with a link can edit? At least it allowed me to restore the previous version of the notes.
FWIW, I believe that maintainers (or anybody who works on a regular basis on a project and does “janitorial” work to pay off debt, regardless of the official role) are often in a good position to determine whether a contribution is good for the long term health of the project. These individuals are usually the only ones that have a real overall view of the project and understand how to keep it maintainable – simply because they do exactly that on a regular basis.
I’ve seen many contributions proposed to libc++ that would have increased the complexity of the project while decreasing the cohesiveness of its design. In some cases, it is possible to refactor things such that the proposed addition incurs a reasonable complexity increase. Sometimes, it isn’t possible.
While it’s unavoidable that some contributions will end up increasing the complexity of the project and are still worthwhile contributions, we have to be extremely careful to avoid projects becoming “dumping grounds” for new features. When that happens, the project becomes complex, unmaintainable, and potentially irrelevant.
I’m not familiar with the specific technical decisions involved here so I don’t want to comment on LLD business specifically. However, I do want to note that maintainers often have a unique perspective on the project’s long term health as they are (de facto) responsible for it, and I do hope that the elements of our decision making process (project council, area team, etc) be cognizant of that when determining “consensus”.
5 Likes