When outputting assembly, any OS or processor-specific flags cannot be
represented by symbolic letters, so these are lost in the generated
assembly. This patch therefore prints out the flags in numeric form if
any of these bits are set. This is compatible with how GAS handles
unknown flags, and allows the generation of assembly that can be read by
GAS.
Details
Diff Detail
- Build Status
Buildable 3307 Build 3307: arc lint + arc unit
Event Timeline
Wait, but we do know those flags, so it doesn't make sense to handle as unknown just because GAS does it.
We should support reading both numeric and textual versions, but it makes no sense to emit unknown.
None of the other target-specific flags have textual representations though, and the y symbol for ARM pure code was a proposal that was ultimately rejected. Hence, if these flags are present in the code, their information will be lost in the assembler output as they do not have a textual representation. It is therefore safer to default to a numeric representation that is already understood by both toolchains if these flags are present.
Hi Phrakar. I think you mean that there are no processor or OS specific flags with textual representation. But yes, SHF_ARM_PURECODE is the first of its kind. Makes me wonder if we are better of not having a textual representation at all for the flag.
lib/MC/MCSectionELF.cpp | ||
---|---|---|
95 | I believe that the right style is to give the whole if-else has curly braces ("{", "}") or none. Since you need it at the else clause, you have to add it here as well. |
Yes, since no other OS/processor specific flag has a text equivalent, it might be better to not emit one for purecode at all. This is independent of the fact that these flags are being lost in the assembler output as LLVM currently does not emit them in numeric form.
I believe that the right style is to give the whole if-else has curly braces ("{", "}") or none. Since you need it at the else clause, you have to add it here as well.