[PATCH] D139092: [LLD][ELF] Cortex-M Security Extensions (CMSE) Support
Peter Smith via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Wed Apr 19 10:00:17 PDT 2023
peter.smith added a comment.
Thanks for the updates. I think we're getting close now. I've made an alternative suggestion to how we can redirect symbols which might be more easily localised to the ARM.cpp file.
================
Comment at: lld/ELF/Arch/ARM.cpp:1055
+ warn("entry function '" + sym->getName() +
+ "' disappeared from secure code");
+ }
----------------
Recommend something like:
```
"entry function '" + sym->getName() +"' from CMSE import library is not present in secure application"
```
================
Comment at: lld/ELF/Relocations.cpp:1346
const RelTy &rel = *i;
uint32_t symIndex = rel.getSymbol(config->isMips64EL);
+ StringRef symName = sec->getFile<ELFT>()->getSymbol(symIndex).getName();
----------------
While I think this will work. I'm thinking that there could be a less intrusive way of achieving this. As I understand it when we create SG veneers we have input sections with `sym`, and `__acle_sym` defined to the same address. All relocations and references are to `sym`.
In the current implementation, we redirect relocations from `sym` to `__acle_sym` and then it looks like we overwrite `sym` in finalize with the value of the SG Veneer.
Could we use a similar mechanism to `SymbolTable::wrap()` and essentially exchange `__acle_sym` with `sym` so that all references to `sym` go to `__acle_sym` we are then free to overwrite `sym`?
================
Comment at: lld/ELF/SymbolTable.h:65
+ // Key is the <sym> name.
+ llvm::StringMap<std::pair<Symbol *, Symbol *>> cmseSymMap;
+
----------------
Can we use a struct with named values here rather than a pair for example:
```
struct EntryFunction {
Symbol *acleSeSym;
Symbol *sym;
};
```
I find nested pairs such as `second.first` and `second.second` hard to read.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D139092/new/
https://reviews.llvm.org/D139092
More information about the llvm-commits
mailing list