-
Notifications
You must be signed in to change notification settings - Fork 14.3k
[LLD][COFF] Swap the meaning of symtab and hybridSymtab in hybrid images #135093
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -32,7 +32,7 @@ class COFFLinkerContext : public CommonLinkerContext { | |
SymbolTable symtab; | ||
COFFOptTable optTable; | ||
|
||
// A hybrid ARM64EC symbol table on ARM64X target. | ||
// A native ARM64 symbol table on ARM64X target. | ||
std::optional<SymbolTable> hybridSymtab; | ||
|
||
// Pointer to the ARM64EC symbol table: either symtab for an ARM64EC target or | ||
|
@@ -41,16 +41,17 @@ class COFFLinkerContext : public CommonLinkerContext { | |
|
||
// Returns the appropriate symbol table for the specified machine type. | ||
SymbolTable &getSymtab(llvm::COFF::MachineTypes machine) { | ||
if (hybridSymtab && (machine == ARM64EC || machine == AMD64)) | ||
if (hybridSymtab && machine == ARM64) | ||
return *hybridSymtab; | ||
return symtab; | ||
} | ||
|
||
// Invoke the specified callback for each symbol table. | ||
void forEachSymtab(std::function<void(SymbolTable &symtab)> f) { | ||
f(symtab); | ||
// If present, process the native symbol table first. | ||
if (hybridSymtab) | ||
f(*hybridSymtab); | ||
f(symtab); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I see that we maintain the strict order that we first deal with the native one, then the arm64ec one. I guess this makes a difference for e.g. the order within sections? (Perhaps this case would need a comment?) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes, things should generally work if we change the order, but it would result in a different ordering of some chunks, which would be visible. I’ll add a comment, thanks for the review! |
||
} | ||
|
||
std::vector<ObjFile *> objFileInstances; | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,60 @@ | ||
// REQUIRES: aarch64 | ||
// RUN: split-file %s %t.dir && cd %t.dir | ||
|
||
// RUN: llvm-mc -filetype=obj -triple=aarch64-windows arm64-data-sym.s -o arm64-data-sym.obj | ||
// RUN: llvm-mc -filetype=obj -triple=arm64ec-windows arm64ec-data-sym.s -o arm64ec-data-sym.obj | ||
// RUN: lld-link -machine:arm64x -dll -out:out.dll -map -mapinfo:exports arm64-data-sym.obj arm64ec-data-sym.obj | ||
// RUN: FileCheck %s < out.map | ||
|
||
// CHECK: Start Length Name Class | ||
// CHECK-NEXT: 0001:00000000 00001004H .text CODE | ||
// CHECK-NEXT: 0004:00000000 00000008H .data DATA | ||
// CHECK-NEXT: 0004:00000008 00000000H .bss DATA | ||
// CHECK-EMPTY: | ||
// CHECK-NEXT: Address Publics by Value Rva+Base Lib:Object | ||
// CHECK-EMPTY: | ||
// CHECK-NEXT: 0001:00000000 _DllMainCRTStartup 0000000180001000 arm64-data-sym.obj | ||
// CHECK-NEXT: 0001:00001000 _DllMainCRTStartup 0000000180002000 arm64ec-data-sym.obj | ||
// CHECK-NEXT: 0004:00000000 arm64_data_sym 0000000180005000 arm64-data-sym.obj | ||
// CHECK-NEXT: 0004:00000004 arm64ec_data_sym 0000000180005004 arm64ec-data-sym.obj | ||
// CHECK-EMPTY: | ||
// CHECK-NEXT: entry point at 0002:00000000 | ||
// CHECK-EMPTY: | ||
// CHECK-NEXT: Static symbols | ||
// CHECK-EMPTY: | ||
// CHECK-EMPTY: | ||
// CHECK-NEXT: Exports | ||
// CHECK-EMPTY: | ||
// CHECK-NEXT: ordinal name | ||
// CHECK-EMPTY: | ||
// CHECK-NEXT: 1 arm64ec_data_sym | ||
|
||
#--- arm64ec-data-sym.s | ||
.text | ||
.globl _DllMainCRTStartup | ||
_DllMainCRTStartup: | ||
ret | ||
|
||
.data | ||
.globl arm64ec_data_sym | ||
.p2align 2, 0x0 | ||
arm64ec_data_sym: | ||
.word 0x02020202 | ||
|
||
.section .drectve | ||
.ascii "-export:arm64ec_data_sym,DATA" | ||
|
||
#--- arm64-data-sym.s | ||
.text | ||
.globl _DllMainCRTStartup | ||
_DllMainCRTStartup: | ||
ret | ||
|
||
.data | ||
.globl arm64_data_sym | ||
.p2align 2, 0x0 | ||
arm64_data_sym: | ||
.word 0x01010101 | ||
|
||
.section .drectve | ||
.ascii "-export:arm64_data_sym,DATA" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if a different name than
hybridSymtab
would be more accurate after this step? Then again, I guess hybrid means the combination of arm64ec and arm64, so in that sense I guess "hybrid" still is relevant even if we mean the other one. (I.e. "the other symtab, for the cases when we have two".)There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've been considering using a name like
nativeSymtab
, but I'm not sure that would be an improvement. On targets other than arm64x (and arm64ec in the future),symtab
already refers to the native symbol table, so renaming it could be misleading.