I give up....
westfw:
assumption was that debug information has to be stored into the final executable, thus making it bigger.
The .elf files becomes significantly swollen with debugging information, but it is all is separate linker sections that are easily stripped out when making the .hex files that actually load on the Arduino HW.
Thanks.
Then that debug information would be useful only for an arduino simulator that would use the elf instead of the hex. Am I right ? Because I still haven't read about gdb-ing arduino live code... (I hope someone can contradict me on this 
A copy of Principles of Compiler Design is in my library.
Gries is The Word
SPlatten:
The evidence is in numerous books.
That's not "evidence", that's "theory."
My experience working with assembler dates back to the early 80's with 6502 and Z80.
Obsolete architectures with few registers, and "fast" memory.
when you run out of registers ... it simply switches to the stack.
This might be useful: Calling convention - Wikipedia
Yes, but that doesn't mean that a function call always, or even usually, pushes arguments on the stack.
Four of the Five CPU calling conventions at your reference are described as passing function arguments in registers. The fifth as "sometimes" doing so... You would be hard-pressed to find a function call that passes arguments on the stack in a typical Arduino sketch.
Now, if you have a non-leaf function which is using lots of registers, avr-gcc will still push them on the stack to preserve their values. But the paradigm has definitely shifted from "push arguments on the stack, save registers in the subroutine" to "push argument registers on stack if needed, put new arguments in the registers" in many architectures.
This does point out that this is something that should be investigated when performance is critical. For critical timing, you should ALWAYS be able to look at the assembly code produced, and understand it well enough to detect whether the compiler has done something stupid. Although the "don't try to outsmart the compiler" dictum still applies; it is generally safe to assume that the overhead of function calls is "somewhat minimized" compared to everything else. To be otherwise would be to discourage "good programming practices" ("subroutines are good.")
avr-gcc is in fact rather aggressive about inlining small functions, even with -Os. If you're writing something like a bootloader, you have to go and use special switches "never inline unless you've been told to", or it will swell your program by inlining calls to uart_getc() and similar:
BillW-MacOSX-2<10070> avr-gcc -g -Wall -Os -fno-inline-small-functions -fno-split-wide-types -mshort-calls -mmcu=atmega328p -DF_CPU=16000000L '-DLED_START_FLASHES=3' '-DBAUD_RATE=115200' -c -o optiboot.o optiboot.c
BillW-MacOSX-2<10071> avr-size optiboot.o
text data bss dec hex filename
506 0 0 506 1fa optiboot.o
BillW-MacOSX-2<10072> avr-gcc -g -Wall -Os -fno-split-wide-types -mshort-calls -mmcu=atmega328p -DF_CPU=16000000L '-DLED_START_FLASHES=3' '-DBAUD_RATE=115200' -c -o optiboot.o optiboot.c
BillW-MacOSX-2<10073> avr-size optiboot.o
text data bss dec hex filename
924 0 0 924 39c optiboot.o
debug information would be useful only for an arduino simulator that would use the elf instead of the hex. Am I right ?
Theoretically, a "live" debugger cam get both binary and debugging info from the .elf file, or assume that the .jex file and .elf file match. I'm pretty sure that the Atmel debuggers actually do that...
westfw:
debug information would be useful only for an arduino simulator that would use the elf instead of the hex. Am I right ?
Theoretically, a "live" debugger cam get both binary and debugging info from the .elf file, or assume that the .jex file and .elf file match. I'm pretty sure that the Atmel debuggers actually do that...
You mean the debugger assumes the code currently running on the arduino matches the hex-with-debug-info on the PC. Makes sense... Still I don't get how breakpoints would be handled, but that's just me needing to read something about this stuff...