[llvm] r259641 - [mips] Add SHF_MIPS_GPREL flag to the MIPS .sbss and .sdata sections

[Simon Atanasyan via llvm-commits]

On Mon, Feb 8, 2016 at 2:10 PM, Daniel Sanders
<Daniel.Sanders at imgtec.com> wrote:
>> -----Original Message-----
>> From: Simon Atanasyan [mailto:simon at atanasyan.com]
>> Sent: 06 February 2016 16:55
>> To: Rafael Espíndola; Daniel Sanders
>> Cc: llvm-commits
>> Subject: Re: [llvm] r259641 - [mips] Add SHF_MIPS_GPREL flag to the MIPS
>> .sbss and .sdata sections
>>
>> On Fri, Feb 5, 2016 at 4:44 PM, Rafael Espíndola
>> <rafael.espindola at gmail.com> wrote:
>> > On 5 February 2016 at 07:19, Simon Atanasyan <simon at atanasyan.com>
>> wrote:
>> >> Unfortunately now it is impossible. llvm-mc does not support some
>> >> necessary flags etc.
>> >
>> > Which flags? Is it being worked on? It is *very* scary to be able to
>> > produce a .o to which there is no .s equivalent.
>>
>> I was not correct - llvm-mc does not support MIPS specific .sdata and
>> .sbss directives to create the corresponding sections. Also it does
>> not know about default flags and section types need to be assigned to
>> these sections so ".section .sdata" is accepted but produces .sdata
>> section with no type and no flags.
>>
>> The attached patch partially fixes this problem (.sdata and .sbss
>> directives still unsupported) and converts original test case to .s
>> form. I am not sure about correctness of the selected approach.
>> Daniel, what do you think about that?

> I definitely agree that we should be able use llvm-mc to test this. As
> you've said, the reason we can't right now is that .sdata/.sbss aren't
> implemented. To add to that, the reason they aren't implemented yet is
> because they aren't needed for our first Integrated Assembler
> milestone. This milestone will have been reached when we can recurse
> LLVM, and assemble the linux kernel. We're pretty close on both but
> there's a couple issues remaining.
>
> Your patch looks correct to me w.r.t MIPS but I've a concern for other
> targets. I don't think ELFAsmParser::ParseSectionArguments() should be
> adding SHF_MIPS_* values without first checking whether the target is
> MIPS. Similarly, I don't think we should be adding special default
> flags on targets where .sdata/.sbss aren't special.

Good point. I will fix the patch and send new version for review via
phabricator.

-- 
Simon Atanasyan