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

Christof Douma via llvm-commits llvm-commits at lists.llvm.org
Fri Feb 24 08:51:17 PST 2017


Hi Rafael.

> On 24 Feb 2017, at 13:49, Rafael Avila de Espindola <rafael.espindola at gmail.com> wrote:
> 
> Christof Douma <Christof.Douma at arm.com> writes:
> 
>> Hi Rafael.
>> 
>> There are a few more beside the one that Simon mentioned. You can find them by cross referencing the SHF_* enum values in include/llvm/Support/ELF.h and the code from lib/MC/MCSectionELF.cpp that I moved to printSectionFlags() in this patch. The ones I’ve identified this way are listed below.
>> 
>> Are there any objections to this patch?
> 
> Some of the flags (SHF_COMPRESSED), should not be visible from
> assembly. For the flags that should be visible from assembly, wouldn't
> it be better to add the missing textual representation?

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.

Thanks,
Christof

> Cheers,
> Rafael



More information about the llvm-commits mailing list