[ELF][Objcopy] unable to locate the extended symbol index table after update-section

[Nechda]

Problem:

I'm trying to insert some data into my ELF file. To achieve this, I create a const char array with the attribute __attribute__((section(".rodata.holder"))). Then, I try to insert the data into the object file using llvm-objcopy --update-section. However, during the linking process, I get an error from the linker:

ld.lld: error: found an extended symbol index (5), but unable to locate the extended symbol index table

How to reproduce:

Step 1 : Download and build llvm 21.1.5 tools

git clone https://github.com/llvm/llvm-project.git && cd llvm-project && git checkout llvmorg-21.1.5

mkdir bld && cd bld
cmake -G Ninja -DCMAKE_BUILD_TYPE=Debug -DLLVM_TARGETS_TO_BUILD=X86 -DLLVM_ENABLE_PROJECTS="llvm;clang;lld" ../llvm
ninja clang lld llvm-objcopy

Step 2 : Put broken sources into build directory

Source examples:

// main.cpp
int External(const char*, const char*, const char*) { return 0; }
int main() { return 0; }

//lib.cpp
static __attribute__((section(".rodata.holder"))) const char resource_holder[0x1000] = {0};

int External(const char*, const char*, const char*);

static const int REG1 = External("Range1", resource_holder + 128 * 0, resource_holder + 128 * 1);
static const int REG2 = External("Range2", resource_holder + 128 * 1, resource_holder + 128 * 2);
static const int REG3 = External("Range3", resource_holder + 128 * 2, resource_holder + 128 * 3);

Generate some random binary data:

head -c 4k /dev/urandom > data.bin

Step 3 : Try to compile

./bin/clang++ lib.cpp -c -O0 -g0 -o lib.o

./bin/llvm-objcopy lib.o --update-section=.rodata.holder=data.bin

./bin/clang++ lib.o main.cpp -o a.out -fuse-ld=lld --ld-path=./bin/ld.lld
# ld.lld: error: found an extended symbol index (5), but unable to locate the extended symbol index table

Possible bug(?) explanation

I've spent some time debugging. It seems the problem is related to the code of the Object::updateSectionData function:

llvm-project/llvm/lib/ObjCopy/ELF/ELFObject.cpp

Lines 2160 to 2182 in 3b83e7f

	Error Object::updateSectionData(SecPtr &Sec, ArrayRef<uint8_t> Data) {
	if (!Sec->hasContents())
	return createStringError(
	errc::invalid_argument,
	"section '%s' cannot be updated because it does not have contents",
	Sec->Name.c_str());
	if (Data.size() > Sec->Size && Sec->ParentSegment)
	return createStringError(errc::invalid_argument,
	"cannot fit data of size %zu into section '%s' "
	"with size %" PRIu64 " that is part of a segment",
	Data.size(), Sec->Name.c_str(), Sec->Size);
	if (!Sec->ParentSegment) {
	Sec = std::make_unique<OwnedDataSection>(*Sec, Data);
	} else {
	// The segment writer will be in charge of updating these contents.
	Sec->Size = Data.size();
	UpdatedSections[Sec.get()] = Data;
	}
	return Error::success();
	}

If we create a new section, then there will not be any calls to Object::replaceSections:

llvm-project/llvm/lib/ObjCopy/ELF/ELFObject.cpp

Lines 2173 to 2179 in 3b83e7f

	if (!Sec->ParentSegment) {
	Sec = std::make_unique<OwnedDataSection>(*Sec, Data);
	} else {
	// The segment writer will be in charge of updating these contents.
	Sec->Size = Data.size();
	UpdatedSections[Sec.get()] = Data;
	}

So, the symbols were not updated with the appropriate section index and an error occurred.

Could anyone tell me is it correct behaviour or we should fix it?

[llvmbot]

@llvm/issue-subscribers-tools-llvm-objcopy-strip

Author: Dmitry Nechitaev (Nechda)

## Problem: I'm trying to insert some data into my ELF file. To achieve this, I create a const char array with the attribute `__attribute__((section(".rodata.holder")))`. Then, I try to insert the data into the object file using `llvm-objcopy --update-section`. However, during the linking process, I get an error from the linker:

ld.lld: error: found an extended symbol index (5), but unable to locate the extended symbol index table

How to reproduce:

Step 1 : Download and build llvm 21.1.5 tools

git clone https://github.com/llvm/llvm-project.git && cd llvm-project && git checkout llvmorg-21.1.5

mkdir bld && cd bld
cmake -G Ninja -DCMAKE_BUILD_TYPE=Debug -DLLVM_TARGETS_TO_BUILD=X86 -DLLVM_ENABLE_PROJECTS="llvm;clang;lld" ../llvm
ninja clang lld llvm-objcopy

Step 2 : Put broken sources into build directory

Source examples:

// main.cpp
int External(const char*, const char*, const char*) { return 0; }
int main() { return 0; }

//lib.cpp
static __attribute__((section(".rodata.holder"))) const char resource_holder[0x1000] = {0};

int External(const char*, const char*, const char*);

static const int REG1 = External("Range1", resource_holder + 128 * 0, resource_holder + 128 * 1);
static const int REG2 = External("Range2", resource_holder + 128 * 1, resource_holder + 128 * 2);
static const int REG3 = External("Range3", resource_holder + 128 * 2, resource_holder + 128 * 3);

Generate some random binary data:

head -c 4k /dev/urandom > data.bin

Step 3 : Try to compile

./bin/clang++ lib.cpp -c -O0 -g0 -o lib.o

./bin/llvm-objcopy lib.o --update-section=.rodata.holder=data.bin

./bin/clang++ lib.o main.cpp -o a.out -fuse-ld=lld --ld-path=./bin/ld.lld
# ld.lld: error: found an extended symbol index (5), but unable to locate the extended symbol index table

Possible bug(?) explanation

I've spent some time debugging. It seems the problem is related to the code of the Object::updateSectionData function:

llvm-project/llvm/lib/ObjCopy/ELF/ELFObject.cpp

Lines 2160 to 2182 in 3b83e7f

	Error Object::updateSectionData(SecPtr &Sec, ArrayRef<uint8_t> Data) {
	if (!Sec->hasContents())
	return createStringError(
	errc::invalid_argument,
	"section '%s' cannot be updated because it does not have contents",
	Sec->Name.c_str());
	if (Data.size() > Sec->Size && Sec->ParentSegment)
	return createStringError(errc::invalid_argument,
	"cannot fit data of size %zu into section '%s' "
	"with size %" PRIu64 " that is part of a segment",
	Data.size(), Sec->Name.c_str(), Sec->Size);
	if (!Sec->ParentSegment) {
	Sec = std::make_unique<OwnedDataSection>(*Sec, Data);
	} else {
	// The segment writer will be in charge of updating these contents.
	Sec->Size = Data.size();
	UpdatedSections[Sec.get()] = Data;
	}
	return Error::success();
	}

If we create a new section, then there will not be any calls to Object::replaceSections:

llvm-project/llvm/lib/ObjCopy/ELF/ELFObject.cpp

Lines 2173 to 2179 in 3b83e7f

	if (!Sec->ParentSegment) {
	Sec = std::make_unique<OwnedDataSection>(*Sec, Data);
	} else {
	// The segment writer will be in charge of updating these contents.
	Sec->Size = Data.size();
	UpdatedSections[Sec.get()] = Data;
	}

So, the symbols were not updated with the appropriate section index and an error occurred.

Could anyone tell me is it correct behaviour or we should fix it?

[jh7370]

I'll take a look into the error you're seeing, as it doesn't sound like it should be happening. That being said, it seems like you'd be better off using -I binary (see https://llvm.org/docs/CommandGuide/llvm-objcopy.html#binary-input-and-output) to turn your data into an object file with symbols that you can reference from the rest of your code.

[Nechda]

Thank you for the information about the -I binary option in llvm-objcopy! In the past, I used a sequence of commands such as --add-section and --add-symbol to achieve the same result.

However, the real task I'm trying to solve is more complex, and the proposed flag is not working on Darwin-like platforms (there is no Mach-O value for the supported output formats). The piece of code I described in the issue description was not expected to cause any errors during linking, and I am prepared to fix it for ELF files.

[jh7370]

Not sure I'm following your reference to Darwin-like platforms. llvm-objcopy has completely different code paths for ELF and Mach-O, so any issues with one are unrelated to the behaviour of the other.

Anyway, it doesn't matter. I've gone over the code a bit more and there's definitely a bug here, due to a dangling reference. Specifically, the line of code at

llvm-project/llvm/lib/ObjCopy/ELF/ELFObject.cpp

Line 2174 in 3b83e7f

Sec = std::make_unique<OwnedDataSection>(*Sec, Data);

seems suspicious. This is replacing the existing .rodata.holder SectionBase instance, which ultimately results in that object being deleted. Subsequently, when writing out the symbol table, we hit this line of code to get the section a symbol is defined in. The Symbol here has DefinedIn pointing at the now-deleted SectionBase instance, which means it's garbage and the subsequent code is unlikely to do the right thing.

I suspect, but have not confirmed, that there may be other symptoms of the same issue, e.g. if the updated section was a member of a section group, I suspect the contents of the associated group might get corrupted. I haven't attempted to audit all such situations.

Whether there are other issues or not, I think the correct thing to do is either call replaceSections instead of the naive assignment done in updateSectionData, or possibly just do the replaceSectionReferences loop that is currently only done in replaceSections. I haven't attempted to determine which is the right approach.