Strange Output In Disassembled Binary

[ssnover]

Hello,

I've been working on trying out Rust on the MSP430 Launchpad. I'm currently working through a bug and so I've been looking through the disassembly. Among the output from objdump on a release build I found this, related to this crate:

0000c0d8 <msp430_rt::reset_handler::h8b2ffb16adfdf523>:
    c0d8:	3c 40 02 02 	mov	#514,	r12	;#0x0202
    c0dc:	3d 40 00 02 	mov	#512,	r13	;#0x0200
    c0e0:	0d 9c       	cmp	r12,	r13	;
    c0e2:	05 2c       	jc	$+12     	;abs 0xc0ee

0000c0e4 <.LBB6_1>:
    c0e4:	8d 43 00 00 	mov	#0,	0(r13)	;r3 As==00
    c0e8:	2d 53       	incd	r13		;
    c0ea:	0d 9c       	cmp	r12,	r13	;
    c0ec:	fb 2b       	jnc	$-8      	;abs 0xc0e4

0000c0ee <.LBB6_2>:
    c0ee:	3c 40 02 02 	mov	#514,	r12	;#0x0202
    c0f2:	3d 40 02 02 	mov	#514,	r13	;#0x0202
    c0f6:	0d 9c       	cmp	r12,	r13	;
    c0f8:	08 2c       	jc	$+18     	;abs 0xc10a
    c0fa:	3e 40 14 c1 	mov	#49428,	r14	;#0xc114

0000c0fe <.LBB6_4>:
    c0fe:	3f 4e       	mov	@r14+,	r15	;
    c100:	8d 4f 00 00 	mov	r15,	0(r13)	;
    c104:	2d 53       	incd	r13		;
    c106:	0d 9c       	cmp	r12,	r13	;
    c108:	fa 2b       	jnc	$-10     	;abs 0xc0fe

0000c10a <.LBB6_5>:
    c10a:	b0 12 d2 c0 	call	#49362		;#0xc0d2

There are a number of sections that look closer to some obfuscated code than I'd expect of a typical program. Especially lines c0ee through c0f8. Do I have something wrong with my toolchain perhaps or do sections of this crate commonly output instructions like this? I don't generally use LLVM for MSP430 so I'm not really sure what to expect.

My Rust source for my application is here if it helps: https://github.com/ssnover95/rust-up-lab11

[cr1901]

@ssnover95 What is the exact version of rust nightly you are using?

I just checked the listing from the last time I built my own AT2XT application on Nov 16, 2018, and I found something similar to you:

0000fe2e <msp430_rt::reset_handler::h74527b2206cf5871>:
    fe2e:	3c 40 2a 02 	mov	#554,	r12	;#0x022a
    fe32:	3d 40 00 02 	mov	#512,	r13	;#0x0200
    fe36:	03 3c       	jmp	$+8      	;abs 0xfe3e

0000fe38 <.LBB19_1>:
    fe38:	8d 43 00 00 	mov	#0,	0(r13)	;r3 As==00
    fe3c:	2d 53       	incd	r13		;

0000fe3e <.LBB19_2>:
    fe3e:	0d 9c       	cmp	r12,	r13	;
    fe40:	fb 2b       	jnc	$-8      	;abs 0xfe38
    fe42:	3c 40 2e 02 	mov	#558,	r12	;#0x022e
    fe46:	3d 40 2a 02 	mov	#554,	r13	;#0x022a
    fe4a:	0d 9c       	cmp	r12,	r13	;
    fe4c:	08 2c       	jc	$+18     	;abs 0xfe5e
    fe4e:	3e 40 fe fe 	mov	#65278,	r14	;#0xfefe

0000fe52 <.LBB19_5>:
    fe52:	3f 4e       	mov	@r14+,	r15	;
    fe54:	8d 4f 00 00 	mov	r15,	0(r13)	;
    fe58:	2d 53       	incd	r13		;
    fe5a:	0d 9c       	cmp	r12,	r13	;
    fe5c:	fa 2b       	jnc	$-10     	;abs 0xfe52

0000fe5e <.LBB19_6>:
    fe5e:	b0 12 1e fe 	call	#65054		;#0xfe1e

All this code is related to clearing .bss and copying the .data section. The jumping around appears normal in order to reduce code size. Looks like the initial compares¹ before running memset/memcpy aren't being optimized away though.

The jcs in both my and your code bugs me though. In your code, address 0x0202 should correspond to _ebss, which should point to the first address not assigned to the .bss section. Looks like in both the memset/memcpy case r13 has to be strictly greater than _ebss or _edata before the copy loop terminates?

1. c0e2, c0f8 in your code, and fe4c in my code- fe36 in my code was optimized though!

[ssnover]

active toolchain
----------------
nightly-x86_64-unknown-linux-gnu (default)
rustc 1.32.0-nightly (6f93e93af 2018-11-14)