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

[MiNT] binutils 2.18 (was: RE: strip)



Hi!

Could we make the new binutils not to use d4 for the initial jump behind the
file format header (the instruction in the first few bytes in a binary)?
This is the thing
that makes us do some extra registry save/restore for kernel modules. See my
commit log entry quoted below and see this mail in the mailing list
http://srv1.trusted.cz:4433/pipermail/cz-bobek-lists-aranym/2006-January/008
630.html ).

It should be easy enough to use one of the scratch registers, am I right?
What about d1?

Best Regards

Standa



2005-07-17 Sunday 16:56  Standa Opichal <opichals@seznam.cz>

	* sys/sockets/inet4/ifload.c:

	.XIF loading stall problem workaround hack
	
	All registers are saved/restored around xif's init call. If they are
not
	then the 'dirh' structure in the sys/module.c/load_modules() gets
corrupted
	in during the module's init() method call.


-----Original Message-----
From: mint-bounce@lists.fishpool.fi [mailto:mint-bounce@lists.fishpool.fi]
On Behalf Of Vincent Rivière
Sent: Tuesday, February 05, 2008 8:04 AM
To: mint
Subject: Re: [MiNT] strip

Frank Naumann wrote:
> From the things I heard on the mailinglist, are the binutils 2.18 
> stable and work together with gcc 2.95? If yes we can easily update 
> just the binutils. Then there is no conflict at all :-)

Yes, binutils 2.18 seems stable, there is no known problem with them. 
GCC 2.95 works fine with it.

I would be very happy if binutils 2.18 is adopted as the official MiNT
version.

However, I made 2 important things in the 2.18 patch.
They need some discussion before it can be widely used.

1) Alignment.
GCC 2.95 (and current GCC 4.2.3) have a default alignment of 2 bytes. 
However, binutils 2.13 have a default alignment of 4 bytes. I configured
binutils 2.18 for a default alignement of 2, in order to be consistent with
GCC. It works perfectly, no byte is wasted. However, that default alignment
of 2 might not be the best choice for our platform. That's why I opened a
new thread about alignment some time ago. Now I will have more time to
continue that discussion.

2) Object file format.
gas-2.13 uses the format a.out-mint for .o files. That format has nothing
special: it is a standard a.out format for m68k. Because that format
(actually, only the name) is not supported by the official binutils, they
ave to be patched for supporting it. In binutils 2.18, I didn't include the
patch for the a.out-mint format. Instead, I used the format a.out-zero-big
which has the very same characteristics, and which is natively supported by
the binutils. These 2 formats are binary compatible (the binaries are the
same). I reported yesterday a successful build of Quake, with the Quake
objects in a.out-zero-big format (produced by the cross gas-2.18) and the
libc.a in a.out-mint format (from the Sparemint binaries). The advantage of
not using a.out-mint is to avoid unnecessary non-standard patching. This
change seems good, but it needs the opinion of more people. A new thread
should be opened for that.

When these 2 questions are answered, binutils 2.18 will be ready for release
!

--
Vincent Rivière