llvm-objcopy --redefine-syms Does Not Update Symbols in PE/COFF (.dll) Files

[Harishmcw]

Hi Developers,

When using llvm-objcopy on a PE/COFF .dll file to rename symbols using the --redefine-syms option, the command executes successfully, and the timestamp of the file updates. However, when inspecting the modified .dll, the symbols remain unchanged.

Command Executed:

llvm-objcopy --redefine-syms objcopy.def openblas.dll

Definition File (objcopy.def):

lsame_ scipy_lsame_
xerbla_ scipy_xerbla_
isamax_ scipy_isamax_
isamin_ scipy_isamin_
ismax_ scipy_ismax_

Please confirm whether --redefine-syms is expected to work on PE/COFF .dll files. If not, should it be documented as unsupported? Otherwise, if this is a bug, a fix would be greatly appreciated.

[llvmbot]

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

Author: None (Harishmcw)

Hi Developers,

When using llvm-objcopy on a PE/COFF .dll file to rename symbols using the --redefine-syms option, the command executes successfully, and the timestamp of the file updates. However, when inspecting the modified .dll, the symbols remain unchanged.

Command Executed:

llvm-objcopy --redefine-syms objcopy.def openblas.dll

Definition File (objcopy.def):

lsame_ scipy_lsame_
xerbla_ scipy_xerbla_
isamax_ scipy_isamax_
isamin_ scipy_isamin_
ismax_ scipy_ismax_

Please confirm whether --redefine-syms is expected to work on PE/COFF .dll files. If not, should it be documented as unsupported? Otherwise, if this is a bug, a fix would be greatly appreciated.

[jh7370]

--redefine-syms and --redefine-sym are definitely supposed to both be supported for COFF - see the loop at

llvm-project/llvm/lib/ObjCopy/COFF/COFFObjcopy.cpp

Line 214 in 2af4007

for (Symbol &Sym : Obj.getMutableSymbols()) {

for the actual logic that does the update. There is a test file that tests on a plain COFF object, which passes.

What version of llvm-objcopy are you using?

I tried reproducing locally (long version below) and could do so, but only with a UTF-16 redef.def file, which I'd created by accident. llvm-objcopy does not understand such a file, but also doesn't fail to parse it, resulting in a successful run but no symbols modified. Is that possibly what's happened here?

--- Reproducible efforts below - no need to read, but might be useful in the future, so I've left it as-is. ---

I modified the YAML of one of the test files for COFF llvm-objcopy to include a symbol, then generated the PE/COFF file from that YAML. Specifically, I modified subsystem.test and added this little snippet to the end:

  - Name:            foo
    Value:           0
    SectionNumber:   1
    SimpleType:      IMAGE_SYM_TYPE_NULL
    ComplexType:     IMAGE_SYM_DTYPE_NULL
    StorageClass:    IMAGE_SYM_CLASS_EXTERNAL

I then ran llvm-objcopy on the object with --redefine-sym foo=bar and the result was an object with a bar symbol (and no foo symbol). I then regenerated the object and ran --redefine-syms redef.def with the contents of redef.def as:

foo bar

The resultant object still contained foo (and no bar). After debugging, it turned out the problem was that the redef.def file was saved in UTF-16 encoding.

[Harishmcw]

Hi @jh7370 ,

I'm using LLVM version 19.1.2 on Windows on ARM (WOA) and tested llvm-objcopy with both --redefine-sym and --redefine-syms.

Observations:

• On COFF object files (.obj), symbol renaming works correctly (foo → bar).
• On DLL files (.dll), the symbol renaming does not take effect. The export table still shows the original function names.
• I confirmed that my .def file is in UTF-8 encoding, so it's not the same UTF-16 issue you previously encountered. Is there any known limitation or additional steps required for modifying symbols in DLL files on WOA?

Thanks.

[jh7370]

Ah, I see, you're not talking about the symbols in the COFF symbol table (dumped via e.g. dumpbin /symbols), you're referring to the export table.

That's a separate thing and I don't believe llvm-objcopy tries to update this. Whether or not it should is a different matter. I'm going to call out to @mstorsjo, who is a bit more knowledgeable about these sorts of things.

[Harishmcw]

Thanks for the clarification! Yes, I was referring to the export table rather than the COFF symbol table. If llvm-objcopy does not update the export table, that explains why the symbols in my DLL remain unchanged.

[mstorsjo]

Ah, I see, you're not talking about the symbols in the COFF symbol table (dumped via e.g. dumpbin /symbols), you're referring to the export table.

That's a separate thing and I don't believe llvm-objcopy tries to update this. Whether or not it should is a different matter.

They are indeed different things. As for the first reference whether it should do this, I would check with GNU objcopy what it does. For options that are supported by GNU objcopy, we should strive to matching that behaviour (modulo potential bugs).

(To test this with GNU objcopy, you probably get the most accurate result by testing it on x86; aarch64 PE/COFF support in binutils is quite recent, and I'm not sure how thoroughly it has been tested/used with objcopy.)

If GNU objcopy doesn't change the exports, which I would expect that it doesn't, this would warrant a separate new option. And even when we'd have a decision on what interface it should use, implementing it may not be entirely trivial. The symbol table lives outside of the contents of object files or the PE image, but the DLL export table is part of the linked image, where we can't e.g. easily expand strings in place.

[Harishmcw]

Hi @mstorsjo

I tested objcopy --redefine-syms with GNU objcopy on an x64 machine, but it behaves the same as llvm-objcopy—it does not modify the export table in the DLL. The command executes without errors, but the exported function names remain unchanged.

It seems neither llvm-objcopy nor GNU objcopy supports modifying DLL export tables. Would this require a separate implementation or a new option?

[mstorsjo]

Hi @mstorsjo

I tested objcopy --redefine-syms with GNU objcopy on an x64 machine, but it behaves the same as llvm-objcopy—it does not modify the export table in the DLL. The command executes without errors, but the exported function names remain unchanged.

It seems neither llvm-objcopy nor GNU objcopy supports modifying DLL export tables. Would this require a separate implementation or a new option?

Not sure exactly what you mean here; it should be reasonable to implement it within llvm-objcopy under a new option - it doesn't need to be a separate tool. (Ideally with coordination with GNU objcopy, but if GNU objcopy doesn't have it implemented, it should be fine to pick a new, non-conflicting option name.) But as mentioned above, implementing this isn't totally trivial.