Export the eflags for architectures that want to use them. The current plan is only for ARM, but doing it now, generically will allow us greater flexibility if we want to do other architectures in the future.
Details
Details
Diff Detail
Diff Detail
- Repository
- rS FreeBSD src repository - subversion
- Lint
Lint Passed - Unit
No Test Coverage
Event Timeline
| sys/arm/include/elf.h | ||
|---|---|---|
| 90 | Fixed, but this file (and the similar ones) are a curious mix of spaces and tabs. | |
| sys/arm/include/elf.h | ||
|---|---|---|
| 66–80 | I know this is an unrelated change, but it makes things consistent with all the other architectures despite how AFUd phabricator makes it look. | |
Comment Actions
Generally, yes, this is what we discussed, and it is fine. Still, there are some details that could be improved.
I suggest naming the aux entry AT_EHDRFLAGS. IMO E_FLAGS is too cryptic and underscore was not used in any other name.
Introducing the aux entry for all arches is a waste. There is no use of the e_flags for x86, and so far, there is no indication that any flags appear for non-arm arches. Only defining it on the arches where the flags are used, and then bracketing the imgact_elf.c fixup action with #ifdef AT_EHDRFLAGS is not too much burden. It is fine to have e_flags member of elf_auxargs always defined and initialized.
Comment Actions
OK
Introducing the aux entry for all arches is a waste. There is no use of the e_flags for x86, and so far, there is no indication that any flags appear for non-arm arches. Only defining it on the arches where the flags are used, and then bracketing the imgact_elf.c fixup action with #ifdef AT_EHDRFLAGS is not too much burden. It is fine to have e_flags member of elf_auxargs always defined and initialized.
I believe that MIPS may also need this treatment if we ever want to support n32 and n64 binaries at the same time. I'll change the name and only define it for arm at the moment. The overhead is tiny and it may help solve some transition problems in the future. I don't see any current use for it on x86, though, and the uses on sparc and ppc seem to be not relevant. arm64 is an open question, but I'll defer there until we have more experience with the platform. I'm kinda torn on the mips question, but will defer on that until I can study the issue more closely.