I'm sure I've just overlooked a simple solution.
Consider:
$ cat foo.S lds r24, 0x4c lds r25, 0x41 lds r26, 0x50 $ avr-gcc -mmcu=attiny4 -mmcu=attiny4 -g -Wall -nostartfiles -save-temps foo.S -o foo.elf $ avr-objdump -S foo.elf foo.elf: file format elf32-avr Disassembly of section .text: 00000000 <__ctors_end>: #include <avr/io.h> lds r24, 0x4c 0: 8c a1 lds r24, 0x4c ; 0x80004c <_edata+0xc> lds r25, 0x41 2: 91 a1 lds r25, 0x41 ; 0x800041 <_edata+0x1> lds r26, 0x50 4: a0 a3 lds r26, 0x50 ; 0x800050 <_edata+0x10>
An Intel hex file can be passed to avr-objdump for disassembly:
$ avr-objcopy -O ihex -j .text foo.elf foo.hex $ avr-objdump -Dzmavr foo.hex foo.hex: file format ihex Disassembly of section .sec1: 00000000 <.sec1>: 0: 8c a1 ldd r24, Y+36 ; 0x24 2: 91 a1 ldd r25, Z+33 ; 0x21 4: a0 a3 std Z+32, r26 ; 0x20
The difference is down to the fact that the 'brain-dead' tiny core supports only 16-bit instructions, and has a 16-bit version of the lds/sts instructions (rather than the 32-bit versions supported by the mega core), and the opcode encoding for lds/sts on avrtiny intersects the opcode encodings for ldd/std on the mega (and other) cores.
Now when I try to specify the correct core:
$ avr-objdump -Dzmavrtiny foo.hex foo.hex: file format ihex avr-objdump: can't use supplied machine avrtiny
So it seems that avr-objdump is able to correctly identify the ISA to use when using the .elf as input, but it doesn't recognise the named ISA when passed on the command line.
Do I have the wrong machine type?
EDIT: copy/paste errors