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.