PowerPC section type conflict

Hi, under powerpc targets, using -mrelocatable under some cases triggers
an error during final assembly generation: rs6000_assemble_integer()
calls varasm.c:unlikely_text_section_p(), and the call chain eventually
gets to where the section htab is queried for ".text.unlikely", and
fails because of mismatched section flags: "error: foo causes a section
type conflict"

This seems to happen after rev.167085, 4.6 branch is also affected.

The flag mismatch seems quite straightforward: current_function_decl is
passed in as the decl here, and as it's final assembly now, it is
NULL_TREE. varasm.c:default_section_type_flags() adds SECTION_WRITE to
its return value, and things get borked.

This patch simply adds a condition to the SECTION_CODE case, to include
when decl == NULL_TREE, and the queried section has a .text* name. I
think this should be the intuitive way, and it does allow the testcase
to compile.

Tested on a powerpc target, is this okay for trunk? (and maybe 4.6 too?)

Thanks,
Chung-Lin

2011-12-16  Chung-Lin Tang  <cltang@codesourcery.com>

	gcc/
	* varasm.c (default_section_type_flags): Set SECTION_CODE in
	flags when decl is NULL_TREE, and section name matches ".text*".

On 12/16/2011 03:16 AM, Chung-Lin Tang wrote:
> Hi, under powerpc targets, using -mrelocatable under some cases triggers
> an error during final assembly generation: rs6000_assemble_integer()
> calls varasm.c:unlikely_text_section_p(), and the call chain eventually
> gets to where the section htab is queried for ".text.unlikely", and
> fails because of mismatched section flags: "error: foo causes a section
> type conflict"
> 
> This seems to happen after rev.167085, 4.6 branch is also affected.
> 
> The flag mismatch seems quite straightforward: current_function_decl is
> passed in as the decl here, and as it's final assembly now, it is
> NULL_TREE. varasm.c:default_section_type_flags() adds SECTION_WRITE to
> its return value, and things get borked.

I don't understand what was put into .text.unlikely that was not a
function in the first place?  Did we try to put data there somewhere?


r~

On 2011/12/17 06:21 AM, Richard Henderson wrote:
> On 12/16/2011 03:16 AM, Chung-Lin Tang wrote:
>> Hi, under powerpc targets, using -mrelocatable under some cases triggers
>> an error during final assembly generation: rs6000_assemble_integer()
>> calls varasm.c:unlikely_text_section_p(), and the call chain eventually
>> gets to where the section htab is queried for ".text.unlikely", and
>> fails because of mismatched section flags: "error: foo causes a section
>> type conflict"
>>
>> This seems to happen after rev.167085, 4.6 branch is also affected.
>>
>> The flag mismatch seems quite straightforward: current_function_decl is
>> passed in as the decl here, and as it's final assembly now, it is
>> NULL_TREE. varasm.c:default_section_type_flags() adds SECTION_WRITE to
>> its return value, and things get borked.
> 
> I don't understand what was put into .text.unlikely that was not a
> function in the first place?  Did we try to put data there somewhere?

I don't think it's that kind of problem; the powerpc backend uses
unlikely_text_section_p(), which compares the passed in argument section
and the value of function_section_1(current_function_decl,true).

Since current_function_decl is NULL at assembly phase, it retrieves
".text.unlikely" to test for equality. It's the retrieving/lookup that
fails here, because the default looked-up section flags set when decl ==
NULL does not really seem to make sense (adds SECTION_WRITE).

Chung-Lin

On 12/17/2011 10:36 PM, Chung-Lin Tang wrote:
> I don't think it's that kind of problem; the powerpc backend uses
> unlikely_text_section_p(), which compares the passed in argument section
> and the value of function_section_1(current_function_decl,true).

I think this might be the real bug, or something related.

> Since current_function_decl is NULL at assembly phase, it retrieves
> ".text.unlikely" to test for equality. It's the retrieving/lookup that
> fails here, because the default looked-up section flags set when decl ==
> NULL does not really seem to make sense (adds SECTION_WRITE).

current_function_decl is only null when we're not inside a function.

One possible fix is to test for current_function_section inside
unlikely_text_section_p.  However, I think that begs the question
of what in the world is actually going on in rs6000_assemble_integer.
Why are we testing for emitting data in text sections?

On 2011/12/19 上午 03:18, Richard Henderson wrote:
> On 12/17/2011 10:36 PM, Chung-Lin Tang wrote:
>> I don't think it's that kind of problem; the powerpc backend uses
>> unlikely_text_section_p(), which compares the passed in argument section
>> and the value of function_section_1(current_function_decl,true).
> 
> I think this might be the real bug, or something related.
> 
>> Since current_function_decl is NULL at assembly phase, it retrieves
>> ".text.unlikely" to test for equality. It's the retrieving/lookup that
>> fails here, because the default looked-up section flags set when decl ==
>> NULL does not really seem to make sense (adds SECTION_WRITE).
> 
> current_function_decl is only null when we're not inside a function.
> 
> One possible fix is to test for current_function_section inside
> unlikely_text_section_p.  However, I think that begs the question
> of what in the world is actually going on in rs6000_assemble_integer.
> Why are we testing for emitting data in text sections?

I think I sort of mis-represented the context here; this was not really
during the assembly phase of a function, but already in
toplev.c:output_object_blocks().

I've created a bugzilla PR for this, with a testcase from U-boot, and a
minimal testcase: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51623

Thanks,
Chung-Lin