My mistake here.
I have not used the section attribute myself much and was looking at gcc
code
just passed the right handside of the .section to the attribute string.
# Stub function for foovf (float)
.section .mips16.fn.foovf,"ax",@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
--More--(55%)
On 04/19/2013 08:22 AM, reed kotler wrote:
I tried to report a bug against llvm for not properly handling the
section attribute but they claim that it's not the intention for gcc
to work this way.
I reported it as an X86 problem because it's more generally
understandable to people but actually the problem occurs when mips16
generates stubs for floating point interoperability with mips32.
The gcc documentation ways that the section attribute takes the
section name.
What is the real rule?
Is this "feature" used by other ports except for gcc mips16?
TIA.
Reed
Here is what I reported:
Consider the following code:
void x(int i) __attribute((section(".mySection,\"aw\",@progbits#")));
void x(int i) {
}
If you compile this with gcc you get:
.file "sectbug.c"
.section .mySection,"aw",@progbits#,"ax",@progbits
.globl x
With Clang you get
.file "sectbug.c"
.section ".mySection,\"aw\",@progbits#","ax",@progbits
.globl x