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

[Daniel Sanders]

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