Alan Hourihane wrote:
This warning is issued when the alignment requested by the C compiler (probably ".align 4") is not supported by the assembler. You have patched GCC, but you probably forgot to patch the binutils (or maybe it needs additional patching). The binutils "patch" is actually to use the original version (unpatched) of bfd/cpu-m68k.cI get this building gcc with the above patches..... /ISO/Atari/GCC/gcc-4.2.3-mint-native/m68k-atari-mint/mshort/libstdc ++-v3/include/iosfwd:71: warning: alignment of 'std::basic_stringbuf<char, std::char_traits<char>, std::allocator<char>::_ZTVSt15basic_stringbufIcSt11char_traitsIcESaIcEE' is greater thanmaximum object file alignment. Using 2Oh, this is on mshort, so is it to be expected ?
Hmm... I don't think mshort should produce such warning. Note that mshort is a concept inside GCC, the binutils know nothing about that. Here is an example on m68k-linux : $ cat b.s nop .align 4 rts $ m68k-linux-as b.s -o b.o $ m68k-linux-objdump -h b.o b.o: file format elf32-m68k Sections: Idx Name Size VMA LMA File off Algn 0 .text 00000006 00000000 00000000 00000034 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 1 .data 00000000 00000000 00000000 0000003c 2**2 CONTENTS, ALLOC, LOAD, DATA 2 .bss 00000000 00000000 00000000 0000003c 2**2 ALLOC We can see the .o alignment is 2**2 (4) $ m68k-linux-objdump -d b.o b.o: file format elf32-m68k Disassembly of section .text: 00000000 <.text>: 0: 4e71 nop 2: 0000 4e75 orib #117,%d0 We can see that rts (4e75) is aligned on a 4 byte boundary (offset 4) Try this example with your binutils. Do you get the same result ?PS: This example is stupid, because .align inserts a word with value 0 so an instruction "ori.b" is generated and combined with the rts value
-- Vincent Rivière