AVR Freaks

But that list looks like binary file types supported not "architectures" ?

Anyway I guess there's only one way to get to the bottom of this and that is to either "dry read" the source of objdump or perhaps even run it in an debugger and step its operation to see what "decisions" it is making and why.

Interesting comment here:

https://sourceware.org/git/gitwe...

So sounds like bfd_check_format() is of some interest in this. It lives here:

https://sourceware.org/git/gitwe...

The "meat" seems to start around line 274

Georg-Johan,

But he's starting with hand coded Asm opcodes - not C code generation?

The point seems to be that for the same source that produces an ELF and a HEX that if the ELF if fed to objdump it correctly recognises the architecture somehow and know how to disassemble things like "8c a1" but if you take the HEX that presumably contains the same 8C A1 and try to use -m on the objdump it disassembles it differently.

I think he's really asking what is the magic -m "word" (when using HEX)  that says the same thing as the identity in the ELF did ?

Like Joey I would have expected "-m avrtiny" to do it. I suppose another way to look at this is that as Asm knowledge is added to binutils (is that in bfd or elsewhere?) how are new architectures added to the -m command?

EDIT: actually that prompted me to look for the list. So:

https://sourceware.org/git/gitwe...

appears to be the place and hence:

 102   /* Assembler only.  */
 103   N (16, bfd_mach_avr1, "avr:1", FALSE, & arch_info_struct[1]),
 104 
 105   /* Classic, <= 8K.  */
 106   N (16, bfd_mach_avr2, "avr:2", FALSE, & arch_info_struct[2]),
 107 
 108   /* Classic + MOVW, <= 8K.  */
 109   N (16, bfd_mach_avr25, "avr:25", FALSE, & arch_info_struct[3]),
 110 
 111   /* Classic, > 8K, <= 64K.  */
 112   /* TODO:  addr_bits should be 16, but set to 22 for some following
 113      version of GCC (from 4.3) for backward compatibility.  */
 114   N (22, bfd_mach_avr3, "avr:3", FALSE, & arch_info_struct[4]),
 115 
 116   /* Classic, == 128K.  */
 117   N (22, bfd_mach_avr31, "avr:31", FALSE, & arch_info_struct[5]),
 118 
 119   /* Classic + MOVW + JMP/CALL, > 8K, <= 64K. */
 120   N (16, bfd_mach_avr35, "avr:35", FALSE, & arch_info_struct[6]),
 121 
 122   /* Enhanced, <= 8K.  */
 123   N (16, bfd_mach_avr4, "avr:4", FALSE, & arch_info_struct[7]),
 124 
 125   /* Enhanced, > 8K, <= 64K.  */
 126   /* TODO:  addr_bits should be 16, but set to 22 for some following
 127      version of GCC (from 4.3) for backward compatibility.  */
 128   N (22, bfd_mach_avr5, "avr:5", FALSE, & arch_info_struct[8]),
 129 
 130   /* Enhanced, == 128K.  */
 131   N (22, bfd_mach_avr51, "avr:51", FALSE, & arch_info_struct[9]),
 132 
 133   /* 3-Byte PC.  */
 134   N (22, bfd_mach_avr6, "avr:6", FALSE, & arch_info_struct[10]),
 135 
 136   /* Tiny core (AVR Tiny).  */
 137   N (16, bfd_mach_avrtiny, "avr:100", FALSE, & arch_info_struct[11]),
 138 
 139   /* Xmega 1.  */
 140   N (24, bfd_mach_avrxmega1, "avr:101", FALSE, & arch_info_struct[12]),
 141 
 142   /* Xmega 2.  */
 143   N (24, bfd_mach_avrxmega2, "avr:102", FALSE, & arch_info_struct[13]),
 144 
 145   /* Xmega 3.  */
 146   N (24, bfd_mach_avrxmega3, "avr:103", FALSE, & arch_info_struct[14]),
 147 
 148   /* Xmega 4.  */
 149   N (24, bfd_mach_avrxmega4, "avr:104", FALSE, & arch_info_struct[15]),
 150 
 151   /* Xmega 5.  */
 152   N (24, bfd_mach_avrxmega5, "avr:105", FALSE, & arch_info_struct[16]),
 153 
 154   /* Xmega 6.  */
 155   N (24, bfd_mach_avrxmega6, "avr:106", FALSE, & arch_info_struct[17]),
 156 
 157   /* Xmega 7.  */
 158   N (24, bfd_mach_avrxmega7, "avr:107", FALSE, NULL)

So I guess the answer here is "-m avr:100" ??

(now I'm gonna have to go and test that!...)

BTW just an observation (and the likely reason for the confusion here):

Known MCU names:
  avr1 avr2 avr25 avr3 avr31 avr35 avr4 avr5 avr51 avr6 avrxmega1
  avrxmega2 avrxmega3 avrxmega4 avrxmega5 avrxmega6 avrxmega7 avrtiny
  at90s1200 attiny11 attiny12 attiny15 attiny28 at90s2313 at90s2323
  at90s2333 at90s2343 attiny22 attiny26 at90s4414 at90s4433 at90s4434
  etc.

That is --target-help from avr-gcc. Those generic "family names" at the start of the list differ between the compiler and the binutils.

As we've just seen one uses avrtiny and the other avr:100 and that's also true for all the xmega ones too. I suppose even things like avr4 versus avr:4 are different but one can be derived from the other.

Presumably the naming rules for binutils are "chip_family:issue_number" or something?

Oh and if -i on objdump won't show "avr:4 .. avr:100, etc" then is there anyway to get it to dump it's "known names"?

(having said that, knowing that :100 meant "avrtiny" would be a bit of a leap of faith)

> -m avr:100
 
Great! I wasn't aware of that, and the docs are not very helpful, calling it the "bfdname", and I assumed that is the "target" or "architecture".
 
The tools have several means to categorize devices into "families" or "subsets":
 
-mmcu=avr* of avr-gcc / cc1[plus]: In the old days, -mmcu= served for multilib selection, i.e. to classify the devices according to their instruction set (usually after mapping devices to their respective avr* set). This is different today: First, there are more options for multilib selection like -msp8 and -mshort-calls. Second, options that determine ISA properties like -mrmw are /not/ used for multilib selection, or such options don't even exist (e.g. for DES).
 
__AVR_ARCH__: A built-in define (kind of) provided by the compiler proper or via specs-file so that user-code can use it in preprocessing directives. The number is the same like in the OUTPUT_ARCH of ld script.
 
-mavr* of the linker: Select the "emulation". Each emulation has it's own set of default linker scripts; this is basically the device-"granularity" of binutils, and less fine-grained than gcc's multilibs.
 
avr:100: The "OUTPUT_ARCH" property as specified in the default linker scripts. IIUC binutils could, in principle, check that all modules that are linked together are of the same arch so it could throw an error if one tries to link together incompatible objects. Here are different means that could be used for such sanity checks more fine grained than arch (e.g. not to link different ABI like -f[no]-short-enums together).
 
It would be highly desirable to get some documentation about what exactly are, and what are the differences between: "ARCH", "bfdname", "emulation" and "option". Clearly the -m option is just the name for some arch which is internally represented like a "100" or some enum. And it's also strange that objdump just dumps the "tiny" in -mavrtiny" instead of complaining about unknown arch.

Oh dear God, I never thought of "help" 

(Though connecting :100 to "avrtiny" is still a bit of a leap)