This is the same logic that ld64 uses to determine which sections
contain functions. This was added so that we could determine which
STABS entries should be N_FUN.
Details
- Reviewers
clayborg - Group Reviewers
Restricted Project - Commits
- rGc7dbaec396ef: [lld-macho] Add isCodeSection()
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
lld/MachO/InputSection.cpp | ||
---|---|---|
67 | BTW there is also a S_ATTR_SOME_INSTRUCTIONS attribute we might be able to use and improve. |
lld/MachO/InputSection.cpp | ||
---|---|---|
67 | hmm I don't think ld64 uses S_ATTR_SOME_INSTRUCTIONS to identify code sections. (Though it does ensure that every code section it emits has both S_ATTR_SOME_INSTRUCTIONS and S_ATTR_PURE_INSTRUCTIONS set.) |
lld/MachO/InputSection.cpp | ||
---|---|---|
67 | Out of curiosity, how does S_ATTR_PURE_INSTRUCTIONS interact with LC_DATA_IN_CODE? For example, if Clang ends up emitting an ARM constant pool into the text section (so it's not technically pure instructions), is the section still marked as pure instructions? |
lld/MachO/InputSection.cpp | ||
---|---|---|
67 | To answer my own question, I'm having a hard time getting clang to produce a constant pool for arm64, but at least for armv7, it marks __TEXT,__text as pure instructions despite the constant pool: https://godbolt.org/z/MaT9E1 |
lld/MachO/InputSection.cpp | ||
---|---|---|
67 | thanks for checking that case :) |
BTW there is also a S_ATTR_SOME_INSTRUCTIONS attribute we might be able to use and improve.