[PATCH] D30169: Print unknown section header flags has hex in assembly output

[Christof Douma via llvm-commits]

> On 24 Feb 2017, at 17:31, Rafael Avila de Espindola <rafael.espindola at gmail.com> wrote:
> 
> Christof Douma <Christof.Douma at arm.com> writes:
> 
>> Personally, I agree with you. Having a textual representation is nicer. But I can’t make-up textual representations for those unknown flags. That is really for the owners of those targets. However, this patch does make sure that even without a textual representation, there is a not-nice-but-correct output as a fail-safe solution. Users might start asking questions why there is hex instead of textual output, and that could lead to fixes for the missing textual representation. 
>> 
>> About the SHF_COMPRESSED flag. At first I thought you are right and we should special case that flag. But I am not sure anymore. What should happen if a tool asks the MC layer to emit assembly of a section that it also wants compressed? The options that I can come up with are:
>> 	- emit an error
>> 	- emit .byte directives with the compressed stream and set the SHF_COMPRESSED flag
>> 
>> It seems that currently the MC layer ignores any compression request when emitting assembly but does not produce an error. My point is that the SHF_COMPRESSED flag is already never visible from assembly and if it would be visible, I would have expected the contents to be compressed already.
> 
> But that is the correct behavior for SHF_COMPRESSED. It is an assembler
> option, not a codegen option.
> 
> Do we know for sure that all the flags that are missing are flags that
> are supposed to be set by codegen? Always printing flags when a value is
> unknown doesn't look like a safe behavior.


I always worked from the assumption that these SHF_* variables in MC represent the section header flags. Targets should manage these flags correctly and the assembly output should not ignore them, but should always print them (or they should trigger an lvvm_UNREACHABLE() perhaps). 

Basically: if a target does not want to set a section header flag on its assembly output, it should not set it on that section when targeting assembly.
Is this not the intended usage of these flags?

This patch tries to improve MC on this point. But if my assumption is wrong, please do explain what these SHF_* variables are for.

Regards,
Christof

> Cheers,
> Rafael