fix: deduplicate DT_NEEDED entries by SONAME by deepakshirkem · Pull Request #1022 · qualcomm/eld

deepakshirkem · 2026-04-06T13:12:13Z

Problem

Fixes #50

When multiple shared libraries with the same SONAME are passed to the linker, ELD emits duplicate DT_NEEDED entries for the same SONAME.

Fix

Deduplicate by SONAME string instead of file pointer using llvm::StringSet<>. This matches the behavior of ld.lld and ld.bfd.

Testing

Verified manually using the reproducer from issue #50.

When multiple shared libraries with the same SONAME are passed to the linker, ELD was emitting duplicate DT_NEEDED entries for the same SONAME.

parth-07

We need tests with this patch.

Additionally, we should warn if there are multiple different shared library with the same SO name.

parth-07 · 2026-04-06T13:46:32Z

lib/Target/GNULDBackend.cpp

      const ELFDynObjectFile *dynObjFile = llvm::cast<ELFDynObjectFile>(lib);
-      if (addedLibs.count(dynObjFile->getInput()->getMemArea()))
+      std::string SOName = dynObjFile->getSOName();
+      if (!addedSONAMEs.insert(SOName).second)


We are changing the if-condition without preserving the behavior of the old if-condition. Would it break anything?

Hi @parth-07,

I tested this locally and the behavior is preserved. The old code deduplicated by MemoryArea pointer to prevent the same file from being added twice. The new code deduplicates by SONAME string,
which is strictly stronger:

So the new check covers everything the old one did, plus fixes the bug.

Screenshot With reproduce step at #50

The old code deduplicated by MemoryArea pointer to prevent the same file from being added twice. The new code deduplicates by SONAME string,
which is strictly stronger:

What happens for libraries without any SONAME? Deduplication using SONAME wouldn't work for such libraries.

Hi @parth-07, I investigated this concern and the fix handles this case correctly. Every SONAME library always has a SONAME set before our code runs

eld/lib/Readers/DynamicELFReader.cpp

Lines 122 to 123 in b03021e

if (!hasSOName)

dynObjFile->setSOName(dynObjFile->getFallbackSOName());

getFallbackSOName() returns the resolved file path, which is unique per file. By the time our code runs in sizeDynamic(), every library already has a SONAME set either real or fallback. We never see an empty SONAME.

I am still open to your feedback!

deepakshirkem · 2026-04-06T14:01:20Z

Hi @parth-07,

I will add a test in this patch. I also think emitting a warning for duplicate shared libraries with the same SONAME would make more sense.

Thank You ((::

deepakshirkem · 2026-04-06T19:47:35Z

Hi @parth-07,
I have addressed all the requested changes. Please take a look and let me know if any further changes are needed.

Thank You ::))

quic-seaswara · 2026-04-06T20:16:17Z

lib/Target/GNULDBackend.cpp

    if (llvm::dyn_cast<ELFFileBase>(lib)->isELFNeeded()) {
      const ELFDynObjectFile *dynObjFile = llvm::cast<ELFDynObjectFile>(lib);
-      if (addedLibs.count(dynObjFile->getInput()->getMemArea()))
+      std::string SOName = dynObjFile->getSOName();


llvm::StringRef ?

Hi @quic-seaswara, getSOName() returns std::string by value. Using llvm::StringRef here would result in a dangling reference since the temporary std::string would be destroyed at the end of the full expression.
I did try using llvm::StringRef initially but it resulted in a dangling reference error during compilation.

quic-seaswara · 2026-04-06T20:16:55Z

lib/Target/GNULDBackend.cpp

      const ELFDynObjectFile *dynObjFile = llvm::cast<ELFDynObjectFile>(lib);
-      if (addedLibs.count(dynObjFile->getInput()->getMemArea()))
+      std::string SOName = dynObjFile->getSOName();
+      std::string fileName = dynObjFile->getInput()->getFileName();


can you move filenanme to 990 and use StringRef

quic-seaswara · 2026-04-06T20:17:39Z

lib/Target/GNULDBackend.cpp

+  llvm::StringSet<> addedSONAMEs;
+  llvm::StringMap<std::string> sonameToFile;
  for (auto &lib : m_Module.getDynLibraryList()) {
    if (llvm::dyn_cast<ELFFileBase>(lib)->isELFNeeded()) {


if (!isELFNeeded())
continue;

quic-seaswara · 2026-04-06T20:18:25Z

test/Common/standalone/DtNeededSonameDedup/DtNeededSonameDedup.test

+RUN: %clang %clangopts -fPIC -c %p/Inputs/2.c -o %t1.2.o
+RUN: %link %linkopts %t1.1.o -o %t1.lib1.so -shared -soname=foo
+RUN: %link %linkopts %t1.2.o -o %t1.lib2.so -shared -soname=foo
+RUN: %link %linkopts /dev/null %t1.lib1.so %t1.lib2.so -o %t1.out 2>&1 | %filecheck %s --check-prefix=WARN


why /dev/null ? is it portable to windows ?

quic-seaswara · 2026-04-06T20:18:48Z

test/Common/standalone/DtNeededSonameDedup/DtNeededSonameDedup.test

+RUN: %link %linkopts %t1.2.o -o %t1.lib2.so -shared -soname=foo
+RUN: %link %linkopts /dev/null %t1.lib1.so %t1.lib2.so -o %t1.out 2>&1 | %filecheck %s --check-prefix=WARN
+RUN: %readelf --dynamic %t1.out | %filecheck %s --check-prefix=NEEDED
+#WARN: Warning: Multiple shared libraries with the same SONAME "foo" detected


Does bfd warn ?

bfd and lld does not warn here, they simply emit the first shared library seen when there are multiple libraries with the same SONAME. I requested @deepakshirkem to emit the warning diagnostic here.

quic-seaswara · 2026-04-06T20:19:54Z

include/eld/Diagnostics/DiagReaders.inc

     "Empty archive file: '%0'")
 DIAG(sframe_read_error, DiagnosticEngine::Error,
-     "SFrame Read Error : %0 from file %1")
+     "SFrame Read Error : %0 from file %1")


remove new line

quic-seaswara · 2026-04-06T20:20:15Z

include/eld/Diagnostics/DiagReaders.inc

-     "SFrame Read Error : %0 from file %1")
+     "SFrame Read Error : %0 from file %1")
+DIAG(warn_duplicate_soname, DiagnosticEngine::Warning,
+     "Multiple shared libraries with the same SONAME \"%0\" detected: %1 and %2")


can you use the same format of message used by Gnu Ld or lld ?

quic-seaswara · 2026-04-06T20:21:02Z

test/Common/standalone/DtNeededSonameDedup/Inputs/2.c

@@ -0,0 +1 @@
+int bar() { return 3; }


you can have the same input file to generate two shared libraries ?

When multiple shared libraries with the same SONAME are passed to the linker, ELD was emitting duplicate DT_NEEDED entries. Signed-off-by: deepakshirkem <deepakshirke509@gmail.com>

deepakshirkem · 2026-04-07T14:46:50Z

Hi @quic-seaswara, I have addressed all the requested changes. Please take a look and let me know if any further changes are needed.

Thank You ::))

fix: deduplicate DT_NEEDED entries by SONAME

1b5adf3

When multiple shared libraries with the same SONAME are passed to the linker, ELD was emitting duplicate DT_NEEDED entries for the same SONAME.

deepakshirkem mentioned this pull request Apr 6, 2026

Shared libraries are not identified by the SO name when emitting DT_NEEDED entries #50

Open

parth-07 requested changes Apr 6, 2026

View reviewed changes

deepakshirkem requested a review from parth-07 April 6, 2026 19:48

quic-seaswara requested changes Apr 6, 2026

View reviewed changes

fix: deduplicate DT_NEEDED entries by SONAME and warn on duplicates

5bd591c

When multiple shared libraries with the same SONAME are passed to the linker, ELD was emitting duplicate DT_NEEDED entries. Signed-off-by: deepakshirkem <deepakshirke509@gmail.com>

deepakshirkem force-pushed the fix/dt-needed-soname branch from 1019252 to 5bd591c Compare April 7, 2026 14:26

deepakshirkem requested a review from quic-seaswara April 7, 2026 15:00

	if (!hasSOName)
	dynObjFile->setSOName(dynObjFile->getFallbackSOName());

		@@ -0,0 +1 @@
		int bar() { return 3; } No newline at end of file

Conversation

deepakshirkem commented Apr 6, 2026

Problem

Fix

Testing

Uh oh!

parth-07 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!

deepakshirkem commented Apr 6, 2026

Uh oh!

deepakshirkem commented Apr 6, 2026

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!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

deepakshirkem commented Apr 7, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants