[PATCH] D30291: Handle section header flags redefinitions similar to GAS

[Christof Douma via llvm-commits]

Hi Rafael.

> On 23 Feb 2017, at 18:03, Rafael Avila de Espindola <rafael.espindola at gmail.com> wrote:
> 
> Christof Douma <Christof.Douma at arm.com> writes:
> 
>> The code that controls this is at [1]. It diagnoses flag overrides for some libbfd specific macro’s, but it accepts the rest. From the comment in the else clause there and some chats with engineers that worked on GAS I believe the argument in GAS is that MASKPROC and MASKOS are special because they are target-specific flags in the ELF standard, while the other are all defined there.
> 
> But that seems an argument for producing an error, no? When we don't
> what the flags are, we have to be conservative and assume they conflict.

GAS goes out of its way to allow some section header flags to be overridden, so they seem to disagree. This feature is subsequently used by "gcc -mpure-code” to set the section header flag SHF_ARM_PURECODE on the .text section as follows:
  .section .text,”0x20000006”

Which only work if I am allowed to override the pre-constructed “.text” section.

After looking at that GAS code, I realised that rather than appending the target-specific flags, GAS replaces them. Experiments also show this as well. So the GAS behaviour is that the following assembly:
  .section .text,"0x200006",%progbits
  .section .text,"0x40000006",%progbits

Results in a section with the flags ‘0x40000006’ set.

From what I’ve seen so far in commits, tests, and documentation, the approach LLVM takes is to align its semantics as much as possible with GAS. I guess because there implementation is the de-facto assembly language standard. Are we changing this stance?


>> +// Test we handle overriding OS and PROC specific flags on the builtin .text section
>> +.section .text,"0x200006",%progbits
>> +.section .text,"0x40000006",%progbits
>> 
>> 
>> The distinction of builtin versus regular is also odd. The ELF spec has
>> no such terms.
>> 
>> It is not the ELF spec that I refer to. It is LLVM that has some pre-constructred sections (see: MCObjectFileInfo::initELFMCObjectFileInfo()). For example: the “.text” section exists before even using any directive . I wanted to cover that in this test too.
> 
> Sure, but why is that special? If I remember correctly gas always creates
> a .bss too. Should that be special? Is there any reason for it?

I have no idea why both GAS and LLVM pre-construct various sections. My guess is that LLVM does so because GAS does so. I assume the override of target-specific flags is there as workaround for this hard-coded assumption in both GAS and LLVM.

Even when you tell LLVM not to add an implicit “.text” directive at the start of the assembly file (llvm-mc -n), the “.text” section is still pre-created and any later ".section .text” directive is a redeclaration according to LLVM.

Another possible solution to accept GCC assembly output is to refactor LLVM in such a way that there are no pre-constructed sections when processing assembly. That is probably in line what you want, right? We won’t be able to handle some GAS assembly files but I guess that is deliberate. I’m not sure how big a refactor that will be, though.

Thanks,
Christof

> Cheers,
> Rafael