[LLVMdev] MIPS asm backend emitting weird symbols into object file?

[Sandeep Raju]

Thanks Daniel for the explanation & the quick workaround. I've tested
the patch and it works fine.

The following testcases may need to be updated though:

    LLVM :: CodeGen/Mips/analyzebranch.ll
    LLVM :: CodeGen/Mips/atomic.ll
    LLVM :: CodeGen/Mips/blez_bgez.ll
    LLVM :: CodeGen/Mips/blockaddr.ll
    LLVM :: CodeGen/Mips/fpbr.ll
    LLVM :: CodeGen/Mips/llvm-ir/ashr.ll
    LLVM :: CodeGen/Mips/llvm-ir/indirectbr.ll
    LLVM :: CodeGen/Mips/llvm-ir/lshr.ll
    LLVM :: CodeGen/Mips/llvm-ir/select.ll
    LLVM :: CodeGen/Mips/llvm-ir/shl.ll
    LLVM :: CodeGen/Mips/longbranch.ll
    LLVM :: CodeGen/Mips/octeon.ll
    LLVM :: MC/Mips/cpsetup.s
    LLVM :: MC/Mips/mips3/valid.s
    LLVM :: MC/Mips/mips4/valid.s
    LLVM :: MC/Mips/mips5/valid.s
    LLVM :: MC/Mips/mips64/valid.s
    LLVM :: MC/Mips/mips64r2/valid.s
    LLVM :: MC/Mips/mips64r3/valid.s
    LLVM :: MC/Mips/mips64r5/valid.s

Could you please subscribe me to the "full/correct" fix, whenever that
comes around?

Thanks,
Sandeep

On Mon, May 18, 2015 at 2:41 AM, Daniel Sanders
<Daniel.Sanders at imgtec.com> wrote:
> I've uploaded a patch at http://reviews.llvm.org/D9821. It's not completely correct since it's using the target triple instead of the ABI but it resolves the immediate problems.
>
>> -----Original Message-----
>> From: Daniel Sanders
>> Sent: 18 May 2015 09:50
>> To: 'Sandeep Raju'; LLVM Developers Mailing List
>> Subject: RE: [LLVMdev] MIPS asm backend emitting weird symbols into
>> object file?
>>
>> Hi,
>>
>> Could you attach the assembly output produced by adding -save-temps to
>> your command?
>>
>> I encountered a similar issue over the weekend so I think I might know what
>> the problem is. The current pc symbol '.' is implemented by dropping a
>> private label (currently named $tmp*) and referencing that. Private labels
>> aren't supposed to appear in the object output for the N32/N64. They
>> currently appear because the private label naming convention is ABI
>> dependant and LLVM doesn't know this yet. It turns out that on O32, private
>> labels begin with '$' but on N32/N64 they begin with '.L'. I'll have a patch for
>> this shortly.
>>
>> > -----Original Message-----
>> > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-
>> bounces at cs.uiuc.edu]
>> > On Behalf Of Sandeep Raju
>> > Sent: 15 May 2015 23:15
>> > To: LLVM Developers Mailing List
>> > Subject: [LLVMdev] MIPS asm backend emitting weird symbols into object
>> > file?
>> >
>> > I'm cross-compiling for MIPS. The test-case is as simple as it can be:
>> >
>> > void foo() {}
>> >
>> > $clang -target mips64-octeon-linux -c -B
>> > path/to/cross/compiled/mips/assembler a.c
>> >
>> > And then I look at the object file:
>> >
>> > $ nm a.o
>> > 0000000000000020 t $tmp0
>> > 0000000000000000 T foo
>> >
>> > I would like to know what "$tmp0" is. Furthermore, if I pass -g to
>> > clang, I see a whole bunch of such symbols. Some of them appear to be
>> > MIPS specific DWARF extensions. But the ones I'm not able to figure
>> > out are the $tmp* symbols:
>> >
>> > # nm a.o
>> > 0000000000000000 N $.debug_info_begin0
>> > 0000000000000000 N $debug_cmdline
>> > 0000000000000020 t $debug_end0
>> > 0000000000000000 N $debug_range
>> > 0000000000000000 t $func_begin0
>> > 0000000000000020 t $func_end0
>> > 0000000000000000 N $info_string
>> > 0000000000000000 N $info_string0
>> > 00000000000000a7 N $info_string1
>> > 00000000000000ab N $info_string2
>> > 00000000000000cf N $info_string3
>> > 0000000000000000 N $line_table_start0
>> > 0000000000000004 N $pubNames_begin0
>> > 000000000000001a N $pubNames_end0
>> > 0000000000000000 N $section_abbrev
>> > 0000000000000000 N $section_debug_loc
>> > 0000000000000000 N $section_info
>> > 0000000000000000 N $section_line
>> > 0000000000000004 t $tmp0
>> > 0000000000000008 t $tmp1
>> > 000000000000000c t $tmp2
>> > 0000000000000020 t $tmp3
>> > 0000000000000020 t $tmp4
>> > 0000000000000000 T foo
>> >
>> > These symbols are not from the IR. They seem to be inserted by the
>> > MIPS asm back-end.
>> >
>> > I wouldn't be worried if these are MIPS specific temporary structures
>> > to hold debug/dwarf info and such, but the reason I started to look
>> > into this is that some of the symbols are appearing in the debugger
>> > backtrace (I'm using gdb 7.9) of a mips binary.
>> >
>> > Any suggestions on where to start looking or what they might be?
>> >
>> > Thanks,
>> > Sandeep
>> > _______________________________________________
>> > LLVM Developers mailing list
>> > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev