Re: [avr-gcc-list] Bug? gcc silently assumes mcu model when linking, creating bad executable

[David Brown]

Colin D Bennett wrote:
> Hi,
>
> I spent two days trying to track down why my program was behaving
> unexpectedly -- as in, when I write to a global variable, it does not
> read back as the same value! I finally tracked it down to this:
> the global variable was getting placed at RAM address 0x60 on my
> ATmega88, which is the location of one of the watchdog registers!
>
> It turns out that my Makefile was not passing the -mmcu=X flag when I
> linked my object files together (with avr-gcc), so gcc silently assumed
> that putting the variable at 0x60 is OK.  By adding -mmcu=atmega88 to
> the linker flags, the variable was then placed at RAM address 0x100,
> which then made the code behave properly on the target device.
>
> When you compile code with avr-gcc and avr-libc without specifying
> -mmcu=X, you get a warning; shouldn't it be the same with linking?
> Clearly, the default assumption of the linker will not result in a
> working program for all AVR models, as I have found.
>
> Am I doing something wrong? Should I have got a warning? Should I be
> using 'avr-ld' to link instead of 'avr-gcc'? Do you think that linking
> a program for an unknown AVR MCU model makes sense?
>
> Thanks,
> Colin

When you pass the -mmcu flag to the linker, that sets things like the 
memory areas for flash and ram that are used by the linker.  Without 
such a flag, the linker will assume default values.  These values will 
not be able to take into account the peripherals on your particular 
target avr - no default values would work for all avrs.  But they are 
good enough for simulation of non-hardware-specific avr code - I expect 
(others can correct me here) that the test suite runs with the default 
values.  As for forcing an error if no -mmcu flag is specified, I'd 
imagine it would be possible to change the default values to something 
impractical (such as zero-length memory areas) so that you'd get a 
linker error.  But that would change the way ld has always worked, and I 
think it would interfere with testing.


There are no warnings in avr-gcc if you omit the -mmcu flag.  The only 
warning you get is for some of the avr-libc headers that vary according 
to the flag - <avr/io.h> is the most obvious case.

So yes, you are doing something wrong, as you figured out yourself - you 
have to tell the linker which mcu you are using, so that it can use the 
correct memory areas.  No, you should not be using avr-ld (you *can*, if 
you really want to) - it is normally easiest to use avr-gcc as the 
driver for all compiling, assembling and linking.  And yes, linking a 
program for an unknown mcu makes sense in the context of simulated 
testing of code for the cpu itself.

So the lack of an error message for a missing mcu flag is not a bug - at 
most, it is a feature request which I think is unlikely to be 
implemented.  It is also independent of the version of avr-gcc, as you 
found out, since it would be a matter for avr-ld - which is part of 
binutils, not gcc.  (binutils covers the assembler, the linker, and the 
librarian; gcc covers the compiler, and avr-libc covers the library.)