Indicate ABI in ARM ELF header flags
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
llvm/include/llvm/MC/MCELFStreamer.h | ||
---|---|---|
106 | I'm not sure. I didn't try to factor out things, in order to keep the changes minimal. A refactoring pass might choose to remove IsThumb or IsAndroid. | |
llvm/lib/Target/ARM/MCTargetDesc/ARMELFStreamer.cpp | ||
1204 | I executed git clang-format HEAD~1 before generating this review, so this is the LLVM style. |
Adding folks working on Arm currently.
llvm/lib/Target/ARM/MCTargetDesc/ARMELFStreamer.cpp | ||
---|---|---|
1200 | I don't think this comment is relevant anymore. You're definitely NOT "just maintaining the status quo" here, you're using the target triple to find the right ELF headers. | |
1203 | I'm really uncomfortable with the duplication of the code from ARMTargetMachine, more so because it's slightly different now, and whoever update isTargetHardFloat will not see this one, potentially creating hard-to-detect object generation issues. | |
1205 | Why leave that out in the first place? | |
1238 | This comment is outdated, as above. | |
1570 | This comment is outdated, as above. |
Sorry I think that we shouldn't be setting these flags at all in relocatable objects.
If you look at the definition for these flags in https://github.com/ARM-software/abi-aa/blob/main/aaelf32/aaelf32.rst#52elf-header they are defined for executables only for example:
Set in executable file headers (e_type = ET_EXEC or ET_DYN) to note that the executable file was built to conform to the hardware floating-point procedure-call standard. Compatible with legacy (pre version 5) gcc use as EF_ARM_VFP_FLOAT.
A linker is expected to derive these values from Tag_ABI_VFP_args see https://github.com/ARM-software/abi-aa/blob/main/addenda32/addenda32.rst
Tag_ABI_VFP_args, (=28), uleb128 0 The user intended FP parameter/result passing to conform to AAPCS, base variant 1 The user intended FP parameter/result passing to conform to AAPCS, VFP variant 2 The user intended FP parameter/result passing to conform to tool chain-specific conventions 3 Code is compatible with both the base and VFP variants; the user did not permit non-variadic functions to pass FP parameters/results
You can see this by compiling an object with GCC, there is no ELF flag set for EF_ARM_ABI_FLOAT_HARD, the linker will add it in based on the build attributes.
See https://github.com/llvm/llvm-project/blob/main/lld/ELF/InputFiles.cpp#L699 in LLD for similar logic.
The BuildAttributes can be set directly by the user with .eabi_attribute directive. I believe the compiler should set them automatically and the assembler might be able to set them based on the target. I'd check there if there is a problem.
llvm/lib/Target/ARM/MCTargetDesc/ARMELFStreamer.cpp | ||
---|---|---|
438 | I didn't change any ordering. Could you elaborate? | |
582 | Sure. | |
1200 | I don't know which target triples use EABI version 5 and which ones use different ABIs. That is the reason I'm initializing the variable with EF_ARM_EABI_VER5. The information I'm adding here is about the behavior of the ABI regarding floating point registers. | |
1203 | Same feeling here. Do you propose to factor out the code somewhere? | |
1204 | I verified, and it's still over 80 columns. I'll manually change the code to avoid this. | |
1205 | Because I couldn't propagate the information necessary for that test. I fixed it. | |
1238 | Is MCELFStreamer not clearing the assembler's e_flags anymore? Should I remove this comment? |
@peter.smith, thank you for the analysis! I'm consequently backing out of this patch.
Can this subsume the isandroid" and potentially "is thumb" flags?