[LLVMdev] funny llvm bug

[reed kotler]

This came about in trying to implement some stubs used by gcc mips16 for 
allowing floating point interoperability with mips32.

You get the following looking code from gcc -mips16:

	# Stub function for foovf (float)
	.section	.mips16.fn.foovf,"ax", at progbits
	.align	2
	.set	nomips16
	.set	nomicromips
	.ent	__fn_stub_foovf
	.type	__fn_stub_foovf, @function
__fn_stub_foovf:
	la	$25,foovf
	mfc1	$4,$f12
	jr	$25
	.end	__fn_stub_foovf
	.text
	$__fn_local_foovf = foovf


Not being sure about the restriction of section to just "name", well 
docs can be wrong and not match the code, I Googled for this:

http://stackoverflow.com/questions/6252812/what-does-the-aw-flag-in-the-section-attribute-mean

This implied that it was okay to do what I tried.

I have not looked at how gcc implements this internally but in LLVM I'm 
creating real IR for a function (the stub being in mips32 mode; even 
though the rest of the compilation unit is being compiled in mips16 
mode). This is one (not the only) reason why I implemented the ability 
to switch processor modes on a per function basis.

As Joerg pointed out, I could create the section change myself with 
inline assembly.I'm not really comfortable emitting inline assembly from 
the compiler that has anything other than instructions or something in 
direct support of an instruction stream and not things that could 
interfere with the global sequencing of things like sections by the 
compiler. While users can do this; they are then more responsible for 
making sure that they have not shot themselves in the foot. On the other 
side, since these are "naked" functions, one could argue that changing 
sections is safe to do inside the function itself.
We do have some ability in MIPS16 to do inline assembly in the presence 
of the direct object emitter but I'm not sure if it could do something 
like this right now.

The clean solution is probably to add two additional function attributes 
to cover these additional pieces, namely "ax" and @progbits.

Thoughts?

Reed


On 04/19/2013 03:40 AM, Rafael Espíndola wrote:
>> It is exactly intended to handle section names as what they are --
>> section names. The only reason it works with GCC is because it writes an
>> assembler stream.
>
> +1
>
> Reed, this fails in gcc if you do LTO, no?
>
>> Joerg
>
> Cheers,
> Rafael
>