From mint-bounce@lists.fishpool.fi Mon Feb 11 11:29:43 2008 Message-ID: <47B076F6.70202@freesbee.fr> Date: Mon, 11 Feb 2008 17:25:26 +0100 From: =?UTF-8?B?VmluY2VudCBSaXZpw6hyZQ==?= User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: mint Subject: Re: [MiNT] Binutils 2.18 + GCC 4.2.3 References: <47A9B90E.6060109@freesbee.fr> <1202738558.7695.13.camel@localhost> <47B05918.3010107@freesbee.fr> <1202740534.7695.22.camel@localhost> In-Reply-To: <1202740534.7695.22.camel@localhost> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 11 Feb 2008 16:25:13.0381 (UTC) FILETIME=[ADB89D50:01C86CCA] X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-to: mint-bounce@lists.fishpool.fi X-original-sender: vincent.riviere@freesbee.fr Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: List-subscribe: List-owner: List-post: Alan Hourihane wrote: >>> I 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, std::allocator >>>> ::_ZTVSt15basic_stringbufIcSt11char_traitsIcESaIcEE' is greater than >>> maximum object file alignment. Using 2 >> 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.c > > Oh, 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