[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[avr-gcc-list] avr-objdump behaviour
From: |
Ben Mann |
Subject: |
[avr-gcc-list] avr-objdump behaviour |
Date: |
Thu, 11 Nov 2004 17:14:40 +0800 |
Hi,
I have an AVR project which I would like to optimise a little (a lot) and
for this purpose I hoped to use the avr-objdump output.
Sorry for the length of the message, but I've tried to be brief :S
For some functions avr-objdump places source code lines in the .lst file,
while for others it does not... I can't seem to find documentation (or a
discussion with solution) about this behaviour, however I have a simple demo
below which will reproduce this feature for one apparent 'cause'. Note that
the source code lines (-l) are still clearly referenced, just not included.
Using the following command line,
-----------------------
avr-gcc -g -Os -mmcu=atmega64 -c demo.c
avr-objdump -h -S -l demo.c > demo.lst
-----------------------
compiling this .C file:
-----------------------
void bar();
void foo() {
bar();
}
void bar() {
unsigned char c;
for(c = 255; c != 0; c--)
;
}
-----------------------
Yields .lst file without the source line "bar();" (demo.c:4)
-----------------------
...snip!...
00000000 <bar>:
bar():
.../demo.c:9
}
void bar() {
unsigned char c;
for(c = 255; c != 0; c--)
0: 8f ef ldi r24, 0xFF ; 255
2: 81 50 subi r24, 0x01 ; 1
4: f1 f7 brne .-4 ; 0x2
6: 08 95 ret
00000008 <foo>:
foo():
.../demo.c:4
8: 0e 94 00 00 call 0x0
c: 08 95 ret
-----------------------
The problem (in this case) seems to be "resolved" by using -O0, however for
my larger project this doesn't seem to help (source lines missing for some
functions even *with* -O0).
Also, if the .C file is modified to remove the predeclaration:
-----------------------
void bar() {
unsigned char c;
for(c = 255; c != 0; c--)
;
}
void foo() {
bar();
}
-----------------------
The output is suitable:
-----------------------
...snip!...
00000000 <bar>:
bar():
.../demo2.c:3
void bar() {
unsigned char c;
for(c = 255; c != 0; c--)
0: 8f ef ldi r24, 0xFF ; 255
2: 81 50 subi r24, 0x01 ; 1
4: f1 f7 brne .-4 ; 0x2
6: 08 95 ret
00000008 <foo>:
foo():
.../demo2.c:8
;
}
void foo() {
bar();
8: 0e 94 00 00 call 0x0
c: 08 95 ret
-----------------------
For a "big" project with interrupt vectors etc this behaviour seems too make
the -S option too complex to use.
Is this sort of behaviour normal? I recall a discussion on this topic in the
list however I didn't find any solution in that case.
Regards
Ben Mann
PS The WinAVR release is 20040720 on Windows.
- [avr-gcc-list] avr-objdump behaviour,
Ben Mann <=
Re: [avr-gcc-list] avr-objdump behaviour, Erik Christiansen, 2004/11/15