linker: detect duplicate exported definitions without imports#6750
Conversation
|
|
s-perron
left a comment
s-perron
left a comment
There was a problem hiding this comment.
Please add a test as well.
9cf29ef to
74eb0a5
Compare
|
Hi @s-perron, Could you help review this MR? Thanks. |
|
The test |
Head branch was pushed to by a user without write access
|
The FAddAsm failure was actually caused by this change, not a stale branch: the duplicate-export check Verified locally: full test_link suite passes (92/92), including FAddAsm and the new |
Head branch was pushed to by a user without write access
|
@s-perron I've force-pushed to fix the check-format failure — it's a pure clang-format reformatting of the |
The duplicate-export check in GetImportExportPairs() only triggered while iterating over imports, so when no module imported a symbol the linker never inspected the export table for that name and silently accepted multiple modules exporting the same symbol instead of reporting a One Definition Rule violation. Check the export table directly before the import-matching loop so duplicates are always rejected. LinkOnceODR symbols are already deduplicated into a single entry beforehand, and the function-variants (multitarget) flow legitimately keeps one export per variant, so the check is skipped in that mode via a new allow_multiple_exports flag. Add a test where two modules export the same symbol but neither imports it. Signed-off-by: jiajia Qian <jiajia.qian@nxp.com>
|
Hi @s-perron, the 2 pending workflows still need your approval to run — after the force-push, GitHub requires maintainer |
4 participants
The duplicate-export check in GetImportExportPairs() only triggers when iterating over imports. If no module imports a symbol, the linker never looks up the export table for that name, so multiple modules can each export the same function and spvtools::Link() silently accepts them instead of reporting a One Definition Rule violation.
Add a standalone pass over the exports map before the import-matching loop to reject links where the same symbol name is exported by more than one module. This correctly handles LinkOnceODR symbols because they are already deduplicated into a single export entry by the preceding linkonce processing.
Fixes the piglit clLinkProgram test where two modules each define get_number() with Export linkage but neither imports it.