[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MiNT] Binutils 2.18 + GCC 4.2.3



On Mon, 2008-02-11 at 17:25 +0100, Vincent Rivière wrote:
> 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<char, std::char_traits<char>, std::allocator<char>
> >>>> ::_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

This is what I get.....

b.o:     file format a.out-zero-big

Disassembly of section .text:

00000000 <.text>:
   0:	4e71           	nop
	...
   e:	0000 4e75      	orib #117,%d0
	...

Alan.