Why does it include debug info for one C file but not another?

Go To Last Post
21 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm using release, but under AVR/GNU C Compiler/Debugging I have Active (Release) set to Default (-g2).

 

What is interesting is that in one C file it shows the C lines:

int main(void)
{
 a2c:	cf 93       	push	r28
 a2e:	df 93       	push	r29
 a30:	00 d0       	rcall	.+0      	; 0xa32 <main+0x6>
 a32:	00 d0       	rcall	.+0      	; 0xa34 <main+0x8>
 a34:	00 d0       	rcall	.+0      	; 0xa36 <main+0xa>
 a36:	cd b7       	in	r28, 0x3d	; 61
 a38:	de b7       	in	r29, 0x3e	; 62
  volatile uint8_t c1;
  uint32_t sp;
  uint8_t p1;

  c1=FAT8_MakeFileSystem(0,256,3,138,512,128,384,640,1536);
 a3a:	81 2c       	mov	r8, r1
 a3c:	86 e0       	ldi	r24, 0x06	; 6
 a3e:	98 2e       	mov	r9, r24
 a40:	90 e8       	ldi	r25, 0x80	; 128

 

But in another it starts out doing and then stops:

 

000000c6 <__bad_interrupt>:
  c6:	9c cf       	rjmp	.-200    	; 0x0 <__vectors>

000000c8 <FAT8_get_signature_structure.isra.0>:
    return FAT8_IOFileInfo(FAT8_IO_READ, ADevice, AFileNo, AFileInfo);
  }

uint8_t FAT8_WriteFileInfo(uint8_t ADevice, uint8_t AFileNo, uint8_t *AFileInfo)
  {
    return FAT8_IOFileInfo(FAT8_IO_WRITE, ADevice, AFileNo, AFileInfo);
  c8:	44 e0       	ldi	r20, 0x04	; 4
  ca:	50 e0       	ldi	r21, 0x00	; 0
  cc:	60 e0       	ldi	r22, 0x00	; 0
  ce:	71 e0       	ldi	r23, 0x01	; 1
  d0:	82 e1       	ldi	r24, 0x12	; 18
  d2:	91 e0       	ldi	r25, 0x01	; 1
  d4:	1b d5       	rcall	.+2614   	; 0xb0c <memcmp>
  d6:	89 2b       	or	r24, r25
  d8:	11 f0       	breq	.+4      	; 0xde <FAT8_get_signature_structure.isra.0+0x16>
  da:	83 e0       	ldi	r24, 0x03	; 3
  dc:	08 95       	ret
  de:	80 91 16 01 	lds	r24, 0x0116	; 0x800116 <buffer1+0x4>
  e2:	90 e0       	ldi	r25, 0x00	; 0
  e4:	01 96       	adiw	r24, 0x01	; 1
  e6:	90 93 05 01 	sts	0x0105, r25	; 0x800105 <__data_end+0x1>
  ea:	80 93 04 01 	sts	0x0104, r24	; 0x800104 <__data_end>
  ee:	80 91 17 01 	lds	r24, 0x0117	; 0x800117 <buffer1+0x5>
  f2:	80 93 10 01 	sts	0x0110, r24	; 0x800110 <__data_end+0xc>
  f6:	80 91 18 01 	lds	r24, 0x0118	; 0x800118 <buffer1+0x6>
  fa:	9f ef       	ldi	r25, 0xFF	; 255
  fc:	98 0f       	add	r25, r24
  fe:	9e 3f       	cpi	r25, 0xFE	; 254
 100:	60 f7       	brcc	.-40     	; 0xda <FAT8_get_signature_structure.isra.0+0x12>
 102:	80 93 11 01 	sts	0x0111, r24	; 0x800111 <__data_end+0xd>
 106:	20 91 19 01 	lds	r18, 0x0119	; 0x800119 <buffer1+0x7>
 10a:	8b ef       	ldi	r24, 0xFB	; 251
 10c:	82 0f       	add	r24, r18
 10e:	8b 30       	cpi	r24, 0x0B	; 11
 110:	20 f7       	brcc	.-56     	; 0xda <FAT8_get_signature_structure.isra.0+0x12>
 112:	81 e0       	ldi	r24, 0x01	; 1
 114:	90 e0       	ldi	r25, 0x00	; 0
 116:	02 c0       	rjmp	.+4      	; 0x11c <FAT8_get_signature_structure.isra.0+0x54>
 118:	88 0f       	add	r24, r24
 11a:	99 1f       	adc	r25, r25
 11c:	2a 95       	dec	r18
 11e:	e2 f7       	brpl	.-8      	; 0x118 <FAT8_get_signature_structure.isra.0+0x50>
 120:	90 93 07 01 	sts	0x0107, r25	; 0x800107 <__data_end+0x3>
 124:	80 93 06 01 	sts	0x0106, r24	; 0x800106 <__data_end+0x2>
 128:	80 91 1a 01 	lds	r24, 0x011A	; 0x80011a <buffer1+0x8>
 12c:	90 91 1b 01 	lds	r25, 0x011B	; 0x80011b <buffer1+0x9>
 130:	90 93 09 01 	sts	0x0109, r25	; 0x800109 <__data_end+0x5>
 134:	80 93 08 01 	sts	0x0108, r24	; 0x800108 <__data_end+0x4>
 138:	80 91 1c 01 	lds	r24, 0x011C	; 0x80011c <buffer1+0xa>
 13c:	90 91 1d 01 	lds	r25, 0x011D	; 0x80011d <buffer1+0xb>
 140:	90 93 0b 01 	sts	0x010B, r25	; 0x80010b <__data_end+0x7>
 144:	80 93 0a 01 	sts	0x010A, r24	; 0x80010a <__data_end+0x6>
 148:	80 91 1e 01 	lds	r24, 0x011E	; 0x80011e <buffer1+0xc>
 14c:	90 91 1f 01 	lds	r25, 0x011F	; 0x80011f <buffer1+0xd>
 150:	90 93 0d 01 	sts	0x010D, r25	; 0x80010d <__data_end+0x9>
 154:	80 93 0c 01 	sts	0x010C, r24	; 0x80010c <__data_end+0x8>
 158:	80 91 20 01 	lds	r24, 0x0120	; 0x800120 <buffer1+0xe>
 15c:	90 91 21 01 	lds	r25, 0x0121	; 0x800121 <buffer1+0xf>
 160:	90 93 0f 01 	sts	0x010F, r25	; 0x80010f <__data_end+0xb>
 164:	80 93 0e 01 	sts	0x010E, r24	; 0x80010e <__data_end+0xa>
 168:	80 e0       	ldi	r24, 0x00	; 0
 16a:	08 95       	ret

0000016c <FAT8_parmdevfile_getsig_readfile.isra.8>:
 16c:	cf 93       	push	r28
 16e:	84 30       	cpi	r24, 0x04	; 4
 170:	78 f4       	brcc	.+30     	; 0x190 <FAT8_parmdevfile_getsig_readfile.isra.8+0x24>
 172:	c6 2f       	mov	r28, r22
 174:	a9 df       	rcall	.-174    	; 0xc8 <FAT8_get_signature_structure.isra.0>
 176:	81 11       	cpse	r24, r1
 178:	0c c0       	rjmp	.+24     	; 0x192 <FAT8_parmdevfile_getsig_readfile.isra.8+0x26>
 17a:	6c 2f       	mov	r22, r28
 17c:	70 e0       	ldi	r23, 0x00	; 0
 17e:	80 91 04 01 	lds	r24, 0x0104	; 0x800104 <__data_end>
 182:	90 91 05 01 	lds	r25, 0x0105	; 0x800105 <__data_end+0x1>
 186:	68 17       	cp	r22, r24
 188:	79 07       	cpc	r23, r25
 18a:	10 f4       	brcc	.+4      	; 0x190 <FAT8_parmdevfile_getsig_readfile.isra.8+0x24>
 18c:	80 e0       	ldi	r24, 0x00	; 0
 18e:	01 c0       	rjmp	.+2      	; 0x192 <FAT8_parmdevfile_getsig_readfile.isra.8+0x26>
 190:	82 e0       	ldi	r24, 0x02	; 2
 192:	cf 91       	pop	r28
 194:	08 95       	ret

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The convention is:   Debug has debug information.   Release strips debug information.

 

You develop with regular configurations but "Release" with high Optimisation and without debug.

 

I strongly recommend that you make Project Properties e.g. Symbols, Paths, ... in "All Configurations"

 

Obviously test Release binary thoroughly.    Especially if you have selected different Optimisation,  Link etc.

 

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The only thing I change about Release is the debugging -g2 just to add the C statements into the LSS.  I am pretty sure the binary is still the same.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What makes you think it is not source annotated? I see C source in both cases.

 

(some complex lines of C can generate far more opcodes than simple ones, don't expect 1 to 1)

Last Edited: Sat. May 30, 2020 - 06:57 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Because there are huge sections of code with no source in them like this:

 

0000019e <FAT8_IOFile>:
 19e:	2f 92       	push	r2
 1a0:	3f 92       	push	r3
 1a2:	4f 92       	push	r4
 1a4:	5f 92       	push	r5
 1a6:	6f 92       	push	r6
 1a8:	7f 92       	push	r7
 1aa:	8f 92       	push	r8
 1ac:	9f 92       	push	r9
 1ae:	af 92       	push	r10
 1b0:	bf 92       	push	r11
 1b2:	cf 92       	push	r12
 1b4:	df 92       	push	r13
 1b6:	ef 92       	push	r14
 1b8:	ff 92       	push	r15
 1ba:	0f 93       	push	r16
 1bc:	1f 93       	push	r17
 1be:	cf 93       	push	r28
 1c0:	df 93       	push	r29
 1c2:	cd b7       	in	r28, 0x3d	; 61
 1c4:	de b7       	in	r29, 0x3e	; 62
 1c6:	a2 97       	sbiw	r28, 0x22	; 34
 1c8:	0f b6       	in	r0, 0x3f	; 63
 1ca:	f8 94       	cli
 1cc:	de bf       	out	0x3e, r29	; 62
 1ce:	0f be       	out	0x3f, r0	; 63
 1d0:	cd bf       	out	0x3d, r28	; 61
 1d2:	98 2e       	mov	r9, r24
 1d4:	86 2f       	mov	r24, r22
 1d6:	28 01       	movw	r4, r16
 1d8:	39 01       	movw	r6, r18
 1da:	ab 28       	or	r10, r11
 1dc:	11 f4       	brne	.+4      	; 0x1e2 <FAT8_IOFile+0x44>
 1de:	82 e0       	ldi	r24, 0x02	; 2
 1e0:	95 c0       	rjmp	.+298    	; 0x30c <FAT8_IOFile+0x16e>
 1e2:	64 2f       	mov	r22, r20
 1e4:	c7 df       	rcall	.-114    	; 0x174 <FAT8_parmdevfile_getsig_readfile.isra.8>
 1e6:	81 11       	cpse	r24, r1
 1e8:	91 c0       	rjmp	.+290    	; 0x30c <FAT8_IOFile+0x16e>
 1ea:	ce 01       	movw	r24, r28
 1ec:	01 96       	adiw	r24, 0x01	; 1
 1ee:	9a a3       	std	Y+34, r25	; 0x22
 1f0:	89 a3       	std	Y+33, r24	; 0x21
 1f2:	20 e2       	ldi	r18, 0x20	; 32
 1f4:	fc 01       	movw	r30, r24
 1f6:	11 92       	st	Z+, r1
 1f8:	2a 95       	dec	r18
 1fa:	e9 f7       	brne	.-6      	; 0x1f6 <FAT8_IOFile+0x58>
 1fc:	b0 90 11 01 	lds	r11, 0x0111	; 0x800111 <__data_end+0xd>
 200:	00 91 06 01 	lds	r16, 0x0106	; 0x800106 <__data_end+0x2>
 204:	10 91 07 01 	lds	r17, 0x0107	; 0x800107 <__data_end+0x3>
 208:	a8 01       	movw	r20, r16
 20a:	60 e0       	ldi	r22, 0x00	; 0
 20c:	70 e0       	ldi	r23, 0x00	; 0
 20e:	a1 2c       	mov	r10, r1
 210:	3a 2d       	mov	r19, r10
 212:	20 e0       	ldi	r18, 0x00	; 0
 214:	a0 e0       	ldi	r26, 0x00	; 0
 216:	21 2c       	mov	r2, r1
 218:	31 2c       	mov	r3, r1
 21a:	c1 14       	cp	r12, r1
 21c:	d1 04       	cpc	r13, r1
 21e:	e1 04       	cpc	r14, r1
 220:	f1 04       	cpc	r15, r1
 222:	09 f4       	brne	.+2      	; 0x226 <FAT8_IOFile+0x88>
 224:	66 c0       	rjmp	.+204    	; 0x2f2 <FAT8_IOFile+0x154>
 226:	3f 3f       	cpi	r19, 0xFF	; 255
 228:	09 f4       	brne	.+2      	; 0x22c <FAT8_IOFile+0x8e>
 22a:	65 c0       	rjmp	.+202    	; 0x2f6 <FAT8_IOFile+0x158>
 22c:	3e 3f       	cpi	r19, 0xFE	; 254
 22e:	09 f5       	brne	.+66     	; 0x272 <FAT8_IOFile+0xd4>
 230:	99 20       	and	r9, r9
 232:	09 f4       	brne	.+2      	; 0x236 <FAT8_IOFile+0x98>
 234:	62 c0       	rjmp	.+196    	; 0x2fa <FAT8_IOFile+0x15c>
 236:	e2 2f       	mov	r30, r18
 238:	f0 e0       	ldi	r31, 0x00	; 0
 23a:	ee 5e       	subi	r30, 0xEE	; 238
 23c:	fe 4f       	sbci	r31, 0xFE	; 254
 23e:	30 81       	ld	r19, Z
 240:	3f 3f       	cpi	r19, 0xFF	; 255
 242:	19 f4       	brne	.+6      	; 0x24a <FAT8_IOFile+0xac>
 244:	2b 11       	cpse	r18, r11
 246:	05 c0       	rjmp	.+10     	; 0x252 <FAT8_IOFile+0xb4>
 248:	58 c0       	rjmp	.+176    	; 0x2fa <FAT8_IOFile+0x15c>
 24a:	2b 15       	cp	r18, r11
 24c:	d8 f7       	brcc	.-10     	; 0x244 <FAT8_IOFile+0xa6>
 24e:	2f 5f       	subi	r18, 0xFF	; 255
 250:	f2 cf       	rjmp	.-28     	; 0x236 <FAT8_IOFile+0x98>
 252:	8e ef       	ldi	r24, 0xFE	; 254
 254:	a8 16       	cp	r10, r24
 256:	29 f0       	breq	.+10     	; 0x262 <FAT8_IOFile+0xc4>
 258:	b0 e0       	ldi	r27, 0x00	; 0
 25a:	ae 5e       	subi	r26, 0xEE	; 238
 25c:	be 4f       	sbci	r27, 0xFE	; 254
 25e:	2c 93       	st	X, r18
 260:	03 c0       	rjmp	.+6      	; 0x268 <FAT8_IOFile+0xca>
 262:	a2 2e       	mov	r10, r18
 264:	22 24       	eor	r2, r2
 266:	23 94       	inc	r2
 268:	9e ef       	ldi	r25, 0xFE	; 254
 26a:	90 83       	st	Z, r25
 26c:	32 2f       	mov	r19, r18
 26e:	33 24       	eor	r3, r3
 270:	33 94       	inc	r3
 272:	3b 15       	cp	r19, r11
 274:	08 f0       	brcs	.+2      	; 0x278 <FAT8_IOFile+0xda>
 276:	43 c0       	rjmp	.+134    	; 0x2fe <FAT8_IOFile+0x160>
 278:	e3 2f       	mov	r30, r19
 27a:	e6 95       	lsr	r30
 27c:	e6 95       	lsr	r30
 27e:	e6 95       	lsr	r30
 280:	a1 e0       	ldi	r26, 0x01	; 1
 282:	b0 e0       	ldi	r27, 0x00	; 0
 284:	ac 0f       	add	r26, r28
 286:	bd 1f       	adc	r27, r29
 288:	ae 0f       	add	r26, r30
 28a:	b1 1d       	adc	r27, r1
 28c:	8c 90       	ld	r8, X
 28e:	e3 2f       	mov	r30, r19
 290:	e7 70       	andi	r30, 0x07	; 7
 292:	f0 e0       	ldi	r31, 0x00	; 0
 294:	e4 57       	subi	r30, 0x74	; 116
 296:	ff 4f       	sbci	r31, 0xFF	; 255
 298:	e4 91       	lpm	r30, Z
 29a:	f8 2d       	mov	r31, r8
 29c:	fe 23       	and	r31, r30
 29e:	89 f5       	brne	.+98     	; 0x302 <FAT8_IOFile+0x164>
 2a0:	8e 2a       	or	r8, r30
 2a2:	8c 92       	st	X, r8
 2a4:	44 16       	cp	r4, r20
 2a6:	55 06       	cpc	r5, r21
 2a8:	66 06       	cpc	r6, r22
 2aa:	77 06       	cpc	r7, r23
 2ac:	b8 f4       	brcc	.+46     	; 0x2dc <FAT8_IOFile+0x13e>
 2ae:	f8 01       	movw	r30, r16
 2b0:	e4 19       	sub	r30, r4
 2b2:	f5 09       	sbc	r31, r5
 2b4:	cf 01       	movw	r24, r30
 2b6:	a0 e0       	ldi	r26, 0x00	; 0
 2b8:	b0 e0       	ldi	r27, 0x00	; 0
 2ba:	c8 16       	cp	r12, r24
 2bc:	d9 06       	cpc	r13, r25
 2be:	ea 06       	cpc	r14, r26
 2c0:	fb 06       	cpc	r15, r27
 2c2:	08 f4       	brcc	.+2      	; 0x2c6 <FAT8_IOFile+0x128>
 2c4:	f6 01       	movw	r30, r12
 2c6:	cf 01       	movw	r24, r30
 2c8:	a0 e0       	ldi	r26, 0x00	; 0
 2ca:	b0 e0       	ldi	r27, 0x00	; 0
 2cc:	c8 1a       	sub	r12, r24
 2ce:	d9 0a       	sbc	r13, r25
 2d0:	ea 0a       	sbc	r14, r26
 2d2:	fb 0a       	sbc	r15, r27
 2d4:	48 0e       	add	r4, r24
 2d6:	59 1e       	adc	r5, r25
 2d8:	6a 1e       	adc	r6, r26
 2da:	7b 1e       	adc	r7, r27
 2dc:	e3 2f       	mov	r30, r19
 2de:	f0 e0       	ldi	r31, 0x00	; 0
 2e0:	ee 5e       	subi	r30, 0xEE	; 238
 2e2:	fe 4f       	sbci	r31, 0xFE	; 254
 2e4:	44 1a       	sub	r4, r20
 2e6:	55 0a       	sbc	r5, r21
 2e8:	66 0a       	sbc	r6, r22
 2ea:	77 0a       	sbc	r7, r23
 2ec:	a3 2f       	mov	r26, r19
 2ee:	30 81       	ld	r19, Z
 2f0:	94 cf       	rjmp	.-216    	; 0x21a <FAT8_IOFile+0x7c>
 2f2:	80 e0       	ldi	r24, 0x00	; 0
 2f4:	07 c0       	rjmp	.+14     	; 0x304 <FAT8_IOFile+0x166>
 2f6:	84 e0       	ldi	r24, 0x04	; 4
 2f8:	05 c0       	rjmp	.+10     	; 0x304 <FAT8_IOFile+0x166>
 2fa:	89 e0       	ldi	r24, 0x09	; 9
 2fc:	03 c0       	rjmp	.+6      	; 0x304 <FAT8_IOFile+0x166>
 2fe:	86 e0       	ldi	r24, 0x06	; 6
 300:	01 c0       	rjmp	.+2      	; 0x304 <FAT8_IOFile+0x166>
 302:	85 e0       	ldi	r24, 0x05	; 5
 304:	31 10       	cpse	r3, r1
 306:	80 e0       	ldi	r24, 0x00	; 0
 308:	21 10       	cpse	r2, r1
 30a:	80 e0       	ldi	r24, 0x00	; 0
 30c:	a2 96       	adiw	r28, 0x22	; 34
 30e:	0f b6       	in	r0, 0x3f	; 63
 310:	f8 94       	cli
 312:	de bf       	out	0x3e, r29	; 62
 314:	0f be       	out	0x3f, r0	; 63
 316:	cd bf       	out	0x3d, r28	; 61
 318:	df 91       	pop	r29
 31a:	cf 91       	pop	r28
 31c:	1f 91       	pop	r17
 31e:	0f 91       	pop	r16
 320:	ff 90       	pop	r15
 322:	ef 90       	pop	r14
 324:	df 90       	pop	r13
 326:	cf 90       	pop	r12
 328:	bf 90       	pop	r11
 32a:	af 90       	pop	r10
 32c:	9f 90       	pop	r9
 32e:	8f 90       	pop	r8
 330:	7f 90       	pop	r7
 332:	6f 90       	pop	r6
 334:	5f 90       	pop	r5
 336:	4f 90       	pop	r4
 338:	3f 90       	pop	r3
 33a:	2f 90       	pop	r2
 33c:	08 95       	ret

then there are other parts that seem to have source in them:

 

    //get signature structure
    ret=FAT8_get_signature_structure(ADevice);
 8c4:	05 dc       	rcall	.-2038   	; 0xd0 <FAT8_get_signature_structure.isra.0>
    if (ret!=FAT8_ERROR_NONE)
 8c6:	81 11       	cpse	r24, r1
 8c8:	0d c0       	rjmp	.+26     	; 0x8e4 <FAT8_GetMultipleFileInfo+0x3c>
      return ret;
    if (AStartFileNo+ANoFiles>FAT8_sigstr.files || ANoFiles==0)
 8ca:	9e 01       	movw	r18, r28
 8cc:	21 0f       	add	r18, r17
 8ce:	31 1d       	adc	r19, r1
 8d0:	80 91 04 01 	lds	r24, 0x0104	; 0x800104 <__data_end>
 8d4:	90 91 05 01 	lds	r25, 0x0105	; 0x800105 <__data_end+0x1>
 8d8:	82 17       	cp	r24, r18
 8da:	93 07       	cpc	r25, r19
 8dc:	50 f3       	brcs	.-44     	; 0x8b2 <FAT8_GetMultipleFileInfo+0xa>
 8de:	cd 2b       	or	r28, r29
 8e0:	41 f3       	breq	.-48     	; 0x8b2 <FAT8_GetMultipleFileInfo+0xa>
    //read fct
    ret=FAT8_Device_IO(FAT8_IO_READ, ADevice, FAT8_sigstr.fctaddr, FAT8_sigstr.files, EXT_BUFFER);
    if (ret!=FAT8_ERROR_NONE)
      return ret;

    return FAT8_ERROR_NONE;
 8e2:	80 e0       	ldi	r24, 0x00	; 0
  }
 8e4:	df 91       	pop	r29
 8e6:	cf 91       	pop	r28
 8e8:	1f 91       	pop	r17
 8ea:	08 95       	ret

it seems to start and stop and I'm not sure why.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

bump - any ideas why it does this?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Post your project.
.
Generally lack of DWARF means it wasn't built with -g in the first place, it has been subject to avr-strip or it does contain DWARF but the source files referenced are no longer in the same location.
.
I'd explore the latter if I were you. Remember that ELF/DWARF files do not contain actual C source but simply "file x/line n" references so to annotate the source files need to be in place.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

is that part from a pre-built library ?

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I strongly suggest that you follow world conventions.

 

There is nothing wrong with square wheels but I would start with round ones first.

 

When the round ones are turning nicely,   you can investigate different shapes.

 

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson - the project is in flux, but let me get it to a place where it isn't and I'll post it.  It would be great to figure this out.

 

awneil - Not using any pre-built libraries.

 

david.prentice - I will try the debug option to see if it does any better, this is a good thought.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

How about a full build log?

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

An extract from your #1 code:

uint8_t FAT8_WriteFileInfo(uint8_t ADevice, uint8_t AFileNo, uint8_t *AFileInfo)
  {
    return FAT8_IOFileInfo(FAT8_IO_WRITE, ADevice, AFileNo, AFileInfo);
  c8:	44 e0       	ldi	r20, 0x04	; 4
  ca:	50 e0       	ldi	r21, 0x00	; 0
  cc:	60 e0       	ldi	r22, 0x00	; 0

 

You would expect to see a function call to FAT8_IOFileInfo however there isn't one. I conclude that it's been inlined as part of optimisation or perhaps you requested it. The original source lines no longer exist.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

N.Winterbottom wrote:
You would expect to see a function call to FAT8_IOFileInfo however there isn't one. I conclude that it's been inlined as part of optimisation or perhaps you requested it. The original source lines no longer exist.
If it's "static inline" it may be in a .h not a .c file. But I thought DWARF2 catered for that. Off to try an experiment....

 

EDIT: OK so I tried main.c as:

#include <avr/io.h>
#include "inline_test.h"

int main(void)
{
    /* Replace with your application code */
    while (1)
    {
		PORTB = add(PINB, PIND);
    }
}

and inline_test.h as:

static inline int add(int a, int b) {
	return a + b;
}

and when I build this in the LSS I see:

0000009e <main>:
int main(void)
{
    /* Replace with your application code */
    while (1)
    {
		PORTB = add(PINB, PIND);
  9e:	99 b1       	in	r25, 0x09	; 9
  a0:	83 b1       	in	r24, 0x03	; 3
  a2:	89 0f       	add	r24, r25
  a4:	85 b9       	out	0x05, r24	; 5
  a6:	fb cf       	rjmp	.-10     	; 0x9e <main>

so it *could* be that my example is too trivial but it may be that I have recreated what Alan was seeing. I guess I need to objdump the .debug sections?

Last Edited: Thu. Jun 4, 2020 - 10:45 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OK so looking at the main.s I see:

.global	main
	.type	main, @function
main:
.LFB1:
	.file 1 ".././main.c"
	.loc 1 5 0
	.cfi_startproc
/* prologue: function */
/* frame size = 0 */
/* stack size = 0 */
.L__stack_usage = 0
.L2:
	.loc 1 9 0 discriminator 1
	in r25,0x9	 ;  D.1631, MEM[(volatile uint8_t *)41B]
	.loc 1 9 0 discriminator 1
	in r24,0x3	 ;  D.1631, MEM[(volatile uint8_t *)35B]
	add r24,r25	 ;  D.1631, D.1631
	.loc 1 9 0 discriminator 1
	out 0x5,r24	 ;  MEM[(volatile uint8_t *)37B], D.1631
	rjmp .L2	 ; 
	.cfi_endproc
.LFE1:
	.size	main, .-main
.Letext0:
	.file 2 ".././inline_test.h"
	.file 3 "c:\\program files (x86)\\atmel\\studio\\7.0\\toolchain\\avr8\\avr8-gnu-toolchain\\avr\\include\\stdint.h"

so that defines .file's 1, 2 and 3 and included in that is inline_test.h but the .loc's around the code are all ".loc 1"s meaning they only relate to .file 1 so it's like .file 2 is not referenced at all.

 

Again maybe it's just because this example is too trivial?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Here is a full project with debug/release build.  This code is probably quite buggy and is a generation behind some changes I've made, but I may return to it because my latest code is much larger than I wanted.  Oddly the modified code has C source littered all through it but this does not.  Hopefully this will assist in figuring out why it does this sometimes.

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There is something a bit weird going on here. So I made sure -save-temps was ticked (in the miscellaneous section) then built it and fat8.s contains stuff like:

	.section	.text.FAT8_get_signature_structure.isra.0,"ax",@progbits
	.type	FAT8_get_signature_structure.isra.0, @function
FAT8_get_signature_structure.isra.0:
.LFB28:
	.file 1 ".././fat8.c"
	.loc 1 43 0
	.cfi_startproc
/* prologue: function */
/* frame size = 0 */
/* stack size = 0 */
.L__stack_usage = 0
.LVL0:
	.loc 1 53 0
	ldi r20,lo8(4)
	ldi r21,0
	ldi r22,lo8(FAT8_SIGNATURE)
	ldi r23,hi8(FAT8_SIGNATURE)
	ldi r24,lo8(buffer1)
	ldi r25,hi8(buffer1)
	call memcmp
.LVL1:
	or r24,r25
	breq .L2
.L4:
	.loc 1 54 0
	ldi r24,lo8(3)
	ret
.L2:
	.loc 1 57 0
	lds r24,buffer1+4
	ldi r25,0
	adiw r24,1
	sts FAT8_sigstr+1,r25
	sts FAT8_sigstr,r24
	.loc 1 58 0
	lds r24,buffer1+5
	sts FAT8_sigstr+10,r24
	.loc 1 59 0
	lds r24,buffer1+6
	sts FAT8_sigstr+11,r24
	.loc 1 60 0
	subi r24,lo8(-(-1))
	cpi r24,lo8(-2)
	brsh .L4
	.loc 1 62 0
	lds r24,buffer1+7
	sts FAT8_sigstr+12,r24
	.loc 1 63 0
	subi r24,lo8(-(-5))
	cpi r24,lo8(11)
	brsh .L4
.LBB114:
.LBB115:
	.loc 1 65 0
	lds r24,buffer1+8
	lds r25,buffer1+8+1
	sts FAT8_sigstr+2+1,r25
	sts FAT8_sigstr+2,r24
	.loc 1 66 0
	lds r24,buffer1+12
	lds r25,buffer1+12+1
	sts FAT8_sigstr+4+1,r25
	sts FAT8_sigstr+4,r24
	.loc 1 67 0
	lds r24,buffer1+10
	lds r25,buffer1+10+1
	sts FAT8_sigstr+6+1,r25
	sts FAT8_sigstr+6,r24
	.loc 1 68 0
	lds r24,buffer1+14
	lds r25,buffer1+14+1
	sts FAT8_sigstr+8+1,r25
	sts FAT8_sigstr+8,r24
	ldi r24,0
.LBE115:
.LBE114:
	.loc 1 71 0
	ret
	.cfi_endproc

So a .file 1 is defined as the fat8.c source file. Then there are loads of .loc references. For example:

	.loc 1 43 0
	.cfi_startproc
/* prologue: function */
/* frame size = 0 */
/* stack size = 0 */
.L__stack_usage = 0
.LVL0:
	.loc 1 53 0
	ldi r20,lo8(4)
	ldi r21,0
	ldi r22,lo8(FAT8_SIGNATURE)
	ldi r23,hi8(FAT8_SIGNATURE)
	ldi r24,lo8(buffer1)
	ldi r25,hi8(buffer1)
	call memcmp
.LVL1:
	or r24,r25
	breq .L2
.L4:
	.loc 1 54 0
	ldi r24,lo8(3)
	ret

So that says to me that when this is "annotated" I would expect a copy of line 43 from fat8. to be shown at the entry point. Line 43 is:

static uint8_t FAT8_get_signature_structure(uint8_t ADevice)

then the stuff that precedes the memcmp might be expected to be annotated by line 53, that is:

    if (memcmp(FAT8_EXT_BUFFER, FAT8_SIGNATURE, FAT8_SIGNATURE_SIZE)!=0)

But I'm not seeing this. But something has just struck me as odd. The .file entries say:

	.file 1 ".././fat8.c"

which suggests that it should look for fat8.c at two directory levels above where the .o\.elf file resides but...

D:\>tree /f alan
Folder PATH listing for volume DATA
Volume serial number is 1CF4-86D6
D:\ALAN
│   fat8.c
│   fat8.h
│   GccApplication6.atsln
│   GccApplication6.componentinfo.xml
│   GccApplication6.cproj
│   main.c
│
├───Debug
│       fat8.d
│       fat8.o
│       GccApplication6.eep
│       GccApplication6.elf
│       GccApplication6.hex
│       GccApplication6.lss
│       GccApplication6.map
│       GccApplication6.size
│       GccApplication6.srec
│       main.d
│       main.o
│       makedep.mk
│       Makefile
│
└───Release
        fat8.d
        fat8.i
        fat8.o
        fat8.s
        GccApplication6.eep
        GccApplication6.elf
        GccApplication6.hex
        GccApplication6.lss
        GccApplication6.map
        GccApplication6.size
        GccApplication6.srec
        main.d
        main.i
        main.o
        main.s
        makedep.mk
        Makefile

fat8.c is at .. not ..\.. level?!? So the file reference is to the wrong place ?!?

 

That raises another question in my mind. Usually when AS7 creates Solution/Projects (even just 1 project) it creates solution at one level then project at one level deeper but that is not the case in this solution - so have you somehow "moved the files around" ?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
it creates solution at one level then project at one level deeper

Isn't that an option?

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

There is that box when you make a new project that says "create directory for solution".  I always uncheck it.  I want the project all in one directory.  The absolute path this project is in is "c:\1\test7"

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I recreated the project with a more "normal" layout but it didn't help. So I went back to the one you provided. If I do this:

D:\alan\Release>avr-objdump -S fat8.o

fat8.o:     file format elf32-avr

Disassembly of section .text.FAT8_get_signature_structure.isra.0:

00000000 <FAT8_get_signature_structure.isra.0>:
    ret=FAT8_Device_IO(FAT8_IO_READ, ADevice, 0, FAT8_SIGNATURE_STRUCTURE_SIZE, FAT8_EXT_BUFFER);
    if (ret!=FAT8_ERROR_NONE)
      return ret;

    //verify signature
    if (memcmp(FAT8_EXT_BUFFER, FAT8_SIGNATURE, FAT8_SIGNATURE_SIZE)!=0)
   0:   44 e0           ldi     r20, 0x04       ; 4
   2:   50 e0           ldi     r21, 0x00       ; 0
   4:   60 e0           ldi     r22, 0x00       ; 0
   6:   70 e0           ldi     r23, 0x00       ; 0
   8:   80 e0           ldi     r24, 0x00       ; 0
   a:   90 e0           ldi     r25, 0x00       ; 0
   c:   0e 94 00 00     call    0       ; 0x0 <FAT8_get_signature_structure.isra.0>
  10:   89 2b           or      r24, r25
  12:   01 f0           breq    .+0             ; 0x14 <FAT8_get_signature_structure.isra.0+0x14>
      return FAT8_ERROR_NO_FILE_SYSTEM;
  14:   83 e0           ldi     r24, 0x03       ; 3
  16:   08 95           ret

    //get parameters
    FAT8_sigstr.files=(uint16_t)(FAT8_EXT_BUFFER[FAT8_SIGNATURE_SIZE]+1);
  18:   80 91 00 00     lds     r24, 0x0000
  1c:   90 e0           ldi     r25, 0x00       ; 0
  1e:   01 96           adiw    r24, 0x01       ; 1
  20:   90 93 00 00     sts     0x0000, r25
  24:   80 93 00 00     sts     0x0000, r24
    FAT8_sigstr.fileinfosize=FAT8_EXT_BUFFER[FAT8_SIGNATURE_SIZE+1];
  28:   80 91 00 00     lds     r24, 0x0000
  2c:   80 93 00 00     sts     0x0000, r24
    FAT8_sigstr.clusters=FAT8_EXT_BUFFER[FAT8_SIGNATURE_SIZE+2];
  30:   80 91 00 00     lds     r24, 0x0000
  34:   80 93 00 00     sts     0x0000, r24
    if (FAT8_sigstr.clusters<1 || FAT8_sigstr.clusters>FAT8_MAX_CLUSTERS)
  38:   81 50           subi    r24, 0x01       ; 1
  3a:   8e 3f           cpi     r24, 0xFE       ; 254
  3c:   00 f4           brcc    .+0             ; 0x3e <FAT8_get_signature_structure.isra.0+0x3e>
      return FAT8_ERROR_NO_FILE_SYSTEM;
    FAT8_sigstr.clustersizebitvalue=FAT8_EXT_BUFFER[FAT8_SIGNATURE_SIZE+3];
  3e:   80 91 00 00     lds     r24, 0x0000
  42:   80 93 00 00     sts     0x0000, r24
    if (FAT8_sigstr.clustersizebitvalue<5 || FAT8_sigstr.clustersizebitvalue>15)
  46:   85 50           subi    r24, 0x05       ; 5
  48:   8b 30           cpi     r24, 0x0B       ; 11
  4a:   00 f4           brcc    .+0             ; 0x4c <FAT8_get_signature_structure.isra.0+0x4c>
      return FAT8_ERROR_NO_FILE_SYSTEM;
    FAT8_sigstr.fctaddr=*(uint16_t*)&FAT8_EXT_BUFFER[FAT8_SIGNATURE_SIZE+4];
  4c:   80 91 00 00     lds     r24, 0x0000
  50:   90 91 00 00     lds     r25, 0x0000
  54:   90 93 00 00     sts     0x0000, r25
  58:   80 93 00 00     sts     0x0000, r24
 etc etc 

so as you can see the .file/.loc work OK and this annotates with source. But it's like this is lost when it goes into the ELF. Still trying to work out why...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

BTW I severely need my eyes tested:

	.file 1 ".././fat8.c"

One of those is "." not ".." so this is really just:

	.file 1 "../fat8.c"

which is the "right place" so that was a red herring then !! I noticed this when I tried:

D:\alan\Release>\avr-source\avr-source.exe fat8.s
file 1 = .././fat8.c
file 2 = c:\\program files (x86)\\atmel\\studio\\7.0\\toolchain\\avr8\\avr8-gnu-toolchain\\avr\\include\\stdint.h
file 3 = .././fat8.h
file 4 = c:\\program files (x86)\\atmel\\studio\\7.0\\toolchain\\avr8\\avr8-gnu-toolchain\\avr\\include\\string.h

that produced:

	.section	.text.FAT8_get_signature_structure.isra.0,"ax",@progbits
	.type	FAT8_get_signature_structure.isra.0, @function
FAT8_get_signature_structure.isra.0:
//==> static uint8_t FAT8_get_signature_structure(uint8_t ADevice)
/* prologue: function */
/* frame size = 0 */
/* stack size = 0 */
.L__stack_usage = 0
//==>     if (memcmp(FAT8_EXT_BUFFER, FAT8_SIGNATURE, FAT8_SIGNATURE_SIZE)!=0)
	ldi r20,lo8(4)
	ldi r21,0
	ldi r22,lo8(FAT8_SIGNATURE)
	ldi r23,hi8(FAT8_SIGNATURE)
	ldi r24,lo8(buffer1)
	ldi r25,hi8(buffer1)
	call memcmp
	or r24,r25
	breq .L2
.L4:
//==>       return FAT8_ERROR_NO_FILE_SYSTEM;
	ldi r24,lo8(3)
	ret
.L2:
//==>     FAT8_sigstr.files=(uint16_t)(FAT8_EXT_BUFFER[FAT8_SIGNATURE_SIZE]+1);
	lds r24,buffer1+4
	ldi r25,0
	adiw r24,1
	sts FAT8_sigstr+1,r25
	sts FAT8_sigstr,r24
//==>     FAT8_sigstr.fileinfosize=FAT8_EXT_BUFFER[FAT8_SIGNATURE_SIZE+1];
	lds r24,buffer1+5
	sts FAT8_sigstr+10,r24
//==>     FAT8_sigstr.clusters=FAT8_EXT_BUFFER[FAT8_SIGNATURE_SIZE+2];
	lds r24,buffer1+6
	sts FAT8_sigstr+11,r24
//==>     if (FAT8_sigstr.clusters<1 || FAT8_sigstr.clusters>FAT8_MAX_CLUSTERS)
	subi r24,lo8(-(-1))
	cpi r24,lo8(-2)
	brsh .L4
etc.

so like avr-objdump my own source annotator knows how to read and insert the C source. So the mystery remains how this is being lost at the link to ELF phase.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks clawson - I'm glad others can reproduce the issue.  It seems to happen sometimes for me and not at other times.