Skip to content

Add initial support for creating executables that use symbol versioning#670

Open
parth-07 wants to merge 1 commit intoqualcomm:mainfrom
parth-07:PrimitiveSymbolVersioningExecutables
Open

Add initial support for creating executables that use symbol versioning#670
parth-07 wants to merge 1 commit intoqualcomm:mainfrom
parth-07:PrimitiveSymbolVersioningExecutables

Conversation

@parth-07
Copy link
Contributor

@parth-07 parth-07 commented Dec 21, 2025

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

@parth-07 parth-07 marked this pull request as draft December 21, 2025 15:16
@partaror partaror force-pushed the PrimitiveSymbolVersioningExecutables branch from 038f473 to c25d32e Compare January 2, 2026 08:49
@parth-07 parth-07 force-pushed the PrimitiveSymbolVersioningExecutables branch 2 times, most recently from 9f60a6c to 7a3f2ce Compare January 13, 2026 12:59
@parth-07 parth-07 force-pushed the PrimitiveSymbolVersioningExecutables branch from 7a3f2ce to baa1b94 Compare January 22, 2026 08:07
@parth-07 parth-07 force-pushed the PrimitiveSymbolVersioningExecutables branch 5 times, most recently from 9878f1a to 43e7eab Compare February 10, 2026 21:29
@parth-07 parth-07 marked this pull request as ready for review February 10, 2026 21:29
@partaror 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 partaror requested a review from quic-areg February 10, 2026 21:33
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>
@parth-07 parth-07 force-pushed the PrimitiveSymbolVersioningExecutables branch from 43e7eab to e6c2931 Compare February 11, 2026 08:59
Copy link
Contributor

@quic-seaswara quic-seaswara left a comment

Choose a reason for hiding this comment

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

some initial comments


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

Choose a reason for hiding this comment

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

Why do we do this ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

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).


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

llvm::StringRef getDynStringTable() const;
Copy link
Contributor

Choose a reason for hiding this comment

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

Move it out of symbol versioning for DynStrTabSection and getDynStringTable

Copy link
Contributor Author

Choose a reason for hiding this comment

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

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


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

Choose a reason for hiding this comment

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

can we pass in ResolveInfo here ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

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.

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

Choose a reason for hiding this comment

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

Is there a function that we can use instead ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

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?

return VerSyms[SymIdx] == getSymbolVersionID(SymIdx);
}

uint16_t getOutputVernAuxID(uint16_t InputVerID) {
Copy link
Contributor

Choose a reason for hiding this comment

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

const function

Copy link
Contributor Author

Choose a reason for hiding this comment

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

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

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

Choose a reason for hiding this comment

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

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

Copy link
Contributor Author

Choose a reason for hiding this comment

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

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

OutputVernAuxIDMap[InputVerID] = OutputVerID;
}

const std::vector<uint16_t> &getOutputVernAuxIDMap() const {
Copy link
Contributor

Choose a reason for hiding this comment

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

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

return OutputVernAuxIDMap;
}

const void *getVerDef(uint16_t InputVerID) {
Copy link
Contributor

Choose a reason for hiding this comment

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

const function

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.

2 participants