I'm going to file this bug but it's kind of a blocker for me so maybe
someone has time
to look at it. Should be nearly trivial to fix.
It's a bug in the way the "section" attribute of functions is
processed.
Consider the following code:
void x(int i) __attribute((section(".mySection,\"aw\", at
progbits#")));
void x(int i) {
}
If you compile this with gcc you get:
.file "sectbug.c"
.section .mySection,"aw", at progbits#,"ax", at
progbits
.globl x
With Clang you get
.file "sectbug.c"
.section ".mySection,\"aw\", at
progbits#","ax", at progbits
.globl x
It needs to unquote the string.
reed kotler <rkotler at mips.com> writes:> I'm going to file this bug but it's kind of a blocker for me so maybe > someone has time > to look at it. Should be nearly trivial to fix.Bugs should be reported to http://www.llvm.org/bugs/ Reports sent to the mailing list are very likely to be forgotten.
On Thu, Apr 18, 2013 at 06:57:29PM -0700, reed kotler wrote:> I'm going to file this bug but it's kind of a blocker for me so > maybe someone has time > to look at it. Should be nearly trivial to fix.I don't think this is a bug, but a misfeature in GCC due to the way it does (non-)escaping. Joerg
This is a feature (or bug) of MCSectionELF::PrintSwitchToSection. For
ELF target this function tries to escape string if it founds
'suspicious' character, see implementation in MCSectionELF.cpp:
StringRef name = getSectionName();
if (name.find_first_not_of("0123456789_."
"abcdefghijklmnopqrstuvwxyz"
"ABCDEFGHIJKLMNOPQRSTUVWXYZ") ==
name.npos) {
OS << "\t.section\t" << name;
} else {
OS << "\t.section\t\"";
As section "name" is something like .mySection,\"aw\", at
progbits# ,
this method puts all the string in quotes.
Other targets (COFF and MachO) doesn't have such treatment.
If looks like the code that transforms section names should be
removed. Does anybody know what this transformation is for?
2013/4/19 Joerg Sonnenberger <joerg at
britannica.bec.de>:> On Thu, Apr 18, 2013 at 06:57:29PM -0700, reed kotler wrote:
>> I'm going to file this bug but it's kind of a blocker for me so
>> maybe someone has time
>> to look at it. Should be nearly trivial to fix.
>
> I don't think this is a bug, but a misfeature in GCC due to the way it
> does (non-)escaping.
>
> Joerg
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
--
Thanks,
--Serge