[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: David Brown
Subject: Re: [avr-gcc-list] Bug? gcc silently assumes mcu model when linking, creating bad executable
Date: Sat, 19 Apr 2008 11:28:41 +0200
User-agent: Thunderbird (Windows/20080213)

Colin D Bennett wrote:

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?


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.)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]