Sandeep Raju
2015-May-15 22:15 UTC
[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
Daniel Sanders
2015-May-18 08:49 UTC
[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
Daniel Sanders
2015-May-18 09:41 UTC
[LLVMdev] MIPS asm backend emitting weird symbols into object file?
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
Sandeep Raju
2015-May-18 16:26 UTC
[LLVMdev] MIPS asm backend emitting weird symbols into object file?
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