On Tue, Feb 27, 2018 at 6:01 PM, Roland McGrath <mcgra...@google.com> wrote:
> On Mon, Feb 26, 2018 at 8:11 PM, Ian Lance Taylor <i...@google.com> wrote:
>> You are recreating the conditions used in
>> default_elf_asm_named_section, so I think you ought to have comments
>> referring back and forth between them.
>>
>> This is OK with the two additional comments.
>
> Thanks for the review. I've added those comments.
>
> However, in testing on x86_64-linux-gnu it caused a regression in:
> gcc/testsuite/gcc.target/i386/pr25254.c
> which got the "section type conflict" error.
>
> This is because x86_64_elf_select_section for that case calls:
> get_section (".lrodata", SECTION_LARGE, NULL)
> but something else had previously instantiated the section via
> the section_type_flags logic that now adds in SECTION_NOTYPE.
>
> I addressed this by making get_section accept having SECTION_NOTYPE and not
> as a non-conflict if none of SECTION_BSS et al is present. That seemed
> like a better bet than finding every get_section caller and making sure
> they use SECTION_NOTYPE when appropriate. But I'm not sure if there might
> be some downside to that logic or if there is a third way to resolve this
> that's better than either of those two.
>
> Here's the new patch I'd like to commit. It has no regressions on
> x86_64-linux-gnu, but I'm not set up to test other configurations.
>
>
> gcc/
> 2018-02-27 Roland McGrath <mcgra...@google.com>
>
> PR other/77609
> * varasm.c (default_section_type_flags): Set SECTION_NOTYPE for
> any section for which we don't know a specific type it should have,
> regardless of name. Previously this was done only for the exact
> names ".init_array", ".fini_array", and ".preinit_array".
> (default_elf_asm_named_section): Add comment about
> relationship with default_section_type_flags and SECTION_NOTYPE.
> (get_section): Don't consider it a type conflict if one side has
> SECTION_NOTYPE and the other doesn't, as long as neither has the
> SECTION_BSS et al used in the default_section_type_flags logic.
Still OK, but it should wait until after the tree is back in stage 1.
Ian
