In file included from /usr/include/libelf.h:36:0,
/usr/include/elf.h:323:0: note: this is the location of the previous
#define EM_AVR32 185 /* Amtel 32-bit microprocessor */
At least a comment should be added explaining why the redefinition is needed.
If the intent was to actually redefine the constant a "#undef" should precede
A second warning occurs stating that misleading indentation is present. The
gcc -DHAVE_CONFIG_H -I. -I.. -DCONFIG_DIR=\"/home/braun/local/etc\" -Wall
-Wno-pointer-sign -g -O2 -MT libavrdude
_a-avr.o -MD -MP -MF .deps/libavrdude_a-avr.Tpo -c -o libavrdude_a-avr.o `test
-f 'avr.c' || echo '../'`avr.c
../avr.c: In function ‘avr_tpi_chip_erase’:
../avr.c:83:5: warning: this ‘while’ clause does not guard...
../avr.c:85:3: note: ...this statement, but the latter is misleadingly
indented as if it were guarded by the ‘while
err = pgm->cmd_tpi(pgm, cmd, sizeof(cmd), NULL, 0);
BTW - I created a ./build directory in which I performed the build steps.
Frankly, I have no idea what is the definition for EM_AVR32 that could
actually be found in AVR32 ELF files in the wild ... 0x18ad seems to have been
historically used, but obviously never made it into any official state.
If there are any AVR32 users around, maybe they could comment on that.
I'm confused. What is 0x18AD? The ELF package has a bunch of constants define
for use in the e_machine field of the elf32 and elf64 headers. These are
simple integers ranging from 0 (EM_NONE) to 247 (EM_BPF). These are set by
whatever application creates the ELF formatted file. To my knowledge 0x18AD
doesn't fit this definition!
There is a comment in the elf.h file suggesting using large random numbers for
new architectures. But there is a definition for the 32 bit AVR architecture.
Perhaps 0x18AD is left over from ancient history when the 32 bit AVR
architecture was new? If that's the case then there is a need for two
constants - the official value (185) and the unofficial value (0x18AD).