Add initial support for creating executables that use symbol versioning by parth-07 · Pull Request #670 · qualcomm/eld

parth-07 · 2025-12-21T15:16:33Z

This commit adds primitive support for creating executables that use
shared libraries with symbol versioning information.

quic-seaswara

some initial comments

quic-seaswara · 2026-02-20T22:25:45Z


+#ifdef ELD_ENABLE_SYMBOL_VERSIONING
+  if (PInfo.isDyn() && PInfo.outSymbol() && PInfo.outSymbol()->shouldIgnore())
+    return false;


Why do we do this ?

When for a default versioned symbol such as foo@@V1, both the canonical foo@V1 and the non-canonical foo symbols are selected by the symbol resolution, then we need to discard the non-canonical symbol so that we do not have duplicates in the symbol table. The symbols that were resolving to the non-canonical foo are made to resolve to the canonical symbol foo@V1. All of this happens during the symbol normalization (IRBuilder::normalizeSymbols).

quic-seaswara · 2026-02-20T22:48:03Z

+
+  void setDynStrTabSection(ELFSection *S) { DynStrTabSection = S; }
+
+  llvm::StringRef getDynStringTable() const;


Move it out of symbol versioning for DynStrTabSection and getDynStringTable

Can we move it out of ELD_ENABLE_SYMBOL_VERSIONING block when it is required? Currently, we only need these functions for symbol versioning.

quic-seaswara · 2026-02-20T22:48:54Z

+
+  template <class ELFT>
+  llvm::StringRef getSymbolVersionName(uint32_t SymIdx,
+                                       ResolveInfo::Desc SymDesc) const {


can we pass in ResolveInfo here ?

No, this function is called before the ResolveInfo for the symbol is properly created. And also, here we are referring to the input symbol. With ResolveInfo, we refer to the output symbol.

quic-seaswara · 2026-02-20T22:49:26Z

+      auto VerNameOffset =
+          reinterpret_cast<const typename ELFT::Verdef *>(VerDefs[SymVerID])
+              ->getAux()
+              ->vda_name;


Is there a function that we can use instead ?

This functionality is directly from the LLVM. vda_name member is as specified in the official Elf_Verdaux data structure. Why would a function be better here?

quic-seaswara · 2026-02-23T18:21:52Z

+    return VerSyms[SymIdx] == getSymbolVersionID(SymIdx);
+  }
+
+  uint16_t getOutputVernAuxID(uint16_t InputVerID) {


const function

It cannot be a const function, it may need to resize an internal member.

quic-seaswara · 2026-02-23T18:22:17Z

+  uint16_t getOutputVernAuxID(uint16_t InputVerID) {
+    if (InputVerID >= OutputVernAuxIDMap.size())
+      OutputVernAuxIDMap.resize(InputVerID + 1, 0);
+    return OutputVernAuxIDMap[InputVerID];


Dont use [ as it will create an unnecessary bucket, find and return the value

The line numbers 98-99 ensures that [ will not create a new bucket.

quic-seaswara · 2026-02-23T18:22:58Z

+    OutputVernAuxIDMap[InputVerID] = OutputVerID;
+  }
+
+  const std::vector<uint16_t> &getOutputVernAuxIDMap() const {


Adding comments around functions would be helpful to see how it needs to be used

I have added the comments for some of the relevant functions.

This commit adds primitive support for creating executables that use shared libraries with symbol versioning information. Signed-off-by: Parth Arora <partaror@qti.qualcomm.com>

quic-seaswara

we will do post merge review, dont want to block a big change

parth-07 marked this pull request as draft December 21, 2025 15:16

partaror force-pushed the PrimitiveSymbolVersioningExecutables branch from 038f473 to c25d32e Compare January 2, 2026 08:49

parth-07 force-pushed the PrimitiveSymbolVersioningExecutables branch 2 times, most recently from 9f60a6c to 7a3f2ce Compare January 13, 2026 12:59

parth-07 force-pushed the PrimitiveSymbolVersioningExecutables branch from 7a3f2ce to baa1b94 Compare January 22, 2026 08:07

parth-07 force-pushed the PrimitiveSymbolVersioningExecutables branch 5 times, most recently from 9878f1a to 43e7eab Compare February 10, 2026 21:29

parth-07 marked this pull request as ready for review February 10, 2026 21:29

partaror requested a review from quic-seaswara February 10, 2026 21:30

partaror changed the title ~~[WIP] Add initial support for creating executables that use symbol versioning~~ Add initial support for creating executables that use symbol versioning Feb 10, 2026

partaror requested a review from quic-areg February 10, 2026 21:33

parth-07 force-pushed the PrimitiveSymbolVersioningExecutables branch from 43e7eab to e6c2931 Compare February 11, 2026 08:59

quic-seaswara requested changes Feb 23, 2026

View reviewed changes

parth-07 force-pushed the PrimitiveSymbolVersioningExecutables branch from e6c2931 to 6172bae Compare February 27, 2026 05:15

parth-07 requested a review from quic-seaswara February 27, 2026 05:15

parth-07 force-pushed the PrimitiveSymbolVersioningExecutables branch from 6172bae to 7870188 Compare March 18, 2026 18:31

partaror force-pushed the PrimitiveSymbolVersioningExecutables branch from 7870188 to 7e02899 Compare March 18, 2026 20:11

Add initial support for creating executables that use symbol versioning

1e6cf12

This commit adds primitive support for creating executables that use shared libraries with symbol versioning information. Signed-off-by: Parth Arora <partaror@qti.qualcomm.com>

quic-seaswara force-pushed the PrimitiveSymbolVersioningExecutables branch from 7e02899 to 1e6cf12 Compare March 18, 2026 20:34

quic-seaswara approved these changes Mar 18, 2026

View reviewed changes

quic-seaswara merged commit 32f4ad8 into qualcomm:main Mar 18, 2026
3 checks passed

partaror mentioned this pull request Mar 25, 2026

Creating executables that use shared libraries with symbol versioning information is not supported #904

Closed


		void setDynStrTabSection(ELFSection *S) { DynStrTabSection = S; }

		llvm::StringRef getDynStringTable() const;

Conversation

parth-07 commented Dec 21, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

quic-seaswara left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

quic-seaswara left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

parth-07 commented Dec 21, 2025 •

edited

Loading