Subject: Re: -mcpu vs. binutils 2.13.90.0.18

From: Guido Guenther <[email-masked]>
Date: Tue, 13 May 2003 13:33:16 +0200

On Wed, Mar 19, 2003 at 01:16:52AM +0100, Thiemo Seufer wrote:
> Guido Guenther wrote:
> [snip]
> > > -march=BAR:
> > > Allow opcodes for CPU BAR in addition to the ISA ones.
> > > 
> > > -mtune=BAZ:
> > > Optimize opcode scheduling for CPU BAZ.
> > So to build kernels for say IP22 R5k I'd change the current
> > 	GCCFLAGS += -mcpu=r5000 -mips2 -Wa,--trap
> > to 
> > 	GCCFLAGS += -mabi=o32 -march=R5000 -mtune=R5000 -Wa,--trap
> > where as for R4X00 I use
> > 	GCCFLAGS += -mabi=o32 -march=R4600 -mtune=R4600 -Wa,--trap
> > Correct?
> 
> Yes, this should work. You can leave the -mtune out, since it defaults
> to the value of -march anyway.
Just for completeness: I had to use:
	GCCFLAGS += -mabi=32 -march=r4600 -mtune=r4600 -Wa,--trap
to make gcc-3.3 happy (note the 32 instead of o32). gcc-3.2 doesn't seem
to handle these options correctly at all.
 -- Guido

---

From: Thiemo Seufer <[email-masked]>
Date: Tue, 13 May 2003 21:27:35 +0200

Guido Guenther wrote:
[snip]
> to make gcc-3.3 happy (note the 32 instead of o32).

Yes, IIRC 64 vs. n64 has the same problem.

> gcc-3.2 doesn't seem

AFAICS you can still drop the -mtune part.

Thiemo

---

From: Daniel Jacobowitz <[email-masked]>
Date: Tue, 13 May 2003 15:36:25 -0400

> Yes, IIRC 64 vs. n64 has the same problem.

That's not quite the same: 64 is o64, n64 is n64.  GCC's never called
the 32-bit ABI "o32".

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

---

From: Thiemo Seufer <[email-masked]>
Date: Tue, 13 May 2003 21:59:28 +0200

Daniel Jacobowitz wrote:
[snip]
> That's not quite the same: 64 is o64, n64 is n64.

I don't think so (There's -mabi=o64).
Otherwise I would have built all my NewABI 64bit Executables as
o64 without noticing ever. :-)

> GCC's never called the 32-bit ABI "o32".

True, but it might be clearer if it did.

Thiemo

---

From: Guido Guenther <[email-masked]>
Date: Tue, 13 May 2003 22:11:44 +0200

> Guido Guenther wrote:
[..snip..] 
> Yes, IIRC 64 vs. n64 has the same problem.
I think 64 is o64 not n64.

> AFAICS you can still drop the -mtune part.
Yes, thanks for pointing this out. I'm just leaving this in the Makefile
to know what to change if I want to tune for another cpu.
 -- Guido

---

From: Thiemo Seufer <[email-masked]>
Date: Tue, 13 May 2003 22:50:21 +0200

> I think 64 is o64 not n64.

Strange, you are now the second to say so. Where does this idea stem from?

I just had a look at the gcc sources, the mips*-linux config doesn't
support o64 at all.

Thiemo

---

From: Guido Guenther <[email-masked]>
Date: Wed, 14 May 2003 00:22:15 +0200

> I just had a look at the gcc sources, the mips*-linux config doesn't
It seems I was wrong (I got confused by the way the kernel calls gcc).
Looking at gcc-3.3:

#define ABI_32  0
#define ABI_N32 1
#define ABI_64  2
#define ABI_EABI 3
#define ABI_O64  4

The naming is very "unfortunate", though. We have (n32,64) and (32,o64).
Wouldn't it help to at least allow for n64 and o32 commandline options?
-mabi=32 and -mabi=64 will have to be kept for Irix compatibility
though, I think.
 -- Guido

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Wed, 14 May 2003 12:53:32 +0200 (MET DST)

> -mabi=32 and -mabi=64 will have to be kept for Irix compatibility

 Why unfortunate?  You use "32" and "64" for normal stuff, and the rest
for special cases ("n32" isn't really 32-bit and "o64" isn't really 64-bit
-- both lie in the middle).  Additional aliases of the "n64" and "o32"
form would make more confusion, IMHO. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: [email-masked], PGP key available        +

---

From: Thiemo Seufer <[email-masked]>
Date: Wed, 14 May 2003 17:12:12 +0200

Maciej W. Rozycki wrote:
> -- both lie in the middle).

Exactly this is the sort of confusion which makes the naming unfortunate.
-32 and -64 had never much to do with 32/64 bit but designate ABIs.

> Additional aliases of the "n64" and "o32"

I disagree.

Thiemo

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Wed, 14 May 2003 19:03:49 +0200 (MET DST)

> -32 and -64 had never much to do with 32/64 bit but designate ABIs.

 Well, "32" is 32-bit address/data and "64" is 64-bit address/data. 
That's essentially pure 32-bit and 64-bit, respectively.  Of course some
data format has to be emitted by tools, so there has to be an ABI
associated with each of these variants. 

 And "n32" and "o64" are 32-bit address/64-bit data -- you can use 64-bit
data, e.g. in gas, but you cannot use 64-bit addressing, e.g. a
section/segment cannot be bigger than 4 GB. 

 The naming isn't consistent, indeed -- there could be, say:

- "32" for 32-bit support -- unambiguous, since there is only one
variation,

- "64" for 64-bit support -- requiring an additional option for selecting
the ABI, bailing out without one (or defaulting to a preconfigured ABI).

 Alternatively, there could be no "32" option -- tools configured for
"mips" would only emit 32-bit binaries and tools configured for "mips64" 
-- 64-bit and mixed ones, depending on one of the "64", "o64" and "n32"
options. 

 Of course all options could be renamed to avoid confusion.

> > form would make more confusion, IMHO. 

 I won't insist -- if people find this suitable for them, then it's great.
I won't use these additional aliases, so that's irrelevant for me.

---

From: Thiemo Seufer <[email-masked]>
Date: Wed, 14 May 2003 19:50:11 +0200

Maciej W. Rozycki wrote:
[snip]
> associated with each of these variants. 

That's just backwards. An ABI defines much more, e.g. calling
conventions and GOT sizes. The register size is just another
property of the ABI.

> - "32" for 32-bit support -- unambiguous, since there is only one

This assumption fails if there will ever be an improved 32bit ABI with
e.g. NewABI calling conventions, as the MEABI tried some time ago.

> the ABI, bailing out without one (or defaulting to a preconfigured ABI).

Argh! Once again, the _ABI_ defines if it supports 64bit. For an
ABI-compliant system, there's no point in having a register-size
selection option.

> "mips" would only emit 32-bit binaries

What is a "32-bit binary"? o32, EABI, MEABI or another
yet-to-be-invented one?

> and tools configured for "mips64" 

What's desireable here depends on the target system. For Linux,
the current way is IMHO the best: o32 only for mips-linux, and
o32, n32 and n64 for mips64-linux, with n32 as default.
o64 isn't useful for Linux, and only interesting for backward
compatibility elsewhere.

Thiemo

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Wed, 14 May 2003 20:09:41 +0200 (MET DST)

> conventions and GOT sizes. The register size is just another

 OK -- maybe I am biased because there is only a single ABI for 32-bit and
64-bit binaries each.  So please just forget it.

> o32, n32 and n64 for mips64-linux, with n32 as default.

 Of course the choice of the default should be configurable (for binutils
it probably already is -- I recall Richard Sandiford making changes in
this area, for gcc -- no idea).

---

From: Thiemo Seufer <[email-masked]>
Date: Wed, 14 May 2003 20:42:56 +0200

Maciej W. Rozycki wrote:
[snip]
> it probably already is

It isn't, and probably will never be. Of course you could introduce
just another configuration, with the bfd vector of your choice as
default.

> -- I recall Richard Sandiford making changes in

It would also need a different config which defines a different
MIPS_DEFAULT_ABI.

Thiemo

---

From: Daniel Jacobowitz <[email-masked]>
Date: Wed, 14 May 2003 23:55:07 -0400

> o64 without noticing ever. :-)

You are, of course, right :)

> True, but it might be clearer if it did.

I suppose... too late now.

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Thu, 15 May 2003 13:39:30 +0200 (MET DST)

> just another configuration, with the bfd vector of your choice as

 Hmm, I would assume "mipsn32*-linux" defaults to n32 and "mips64*-linux" 
-- to (n)64.  It isn't the case, indeed.

> It would also need a different config which defines a different

 I will do the change as described above when I am working on mips64
glibc.  Also config.guess will probably have to be updated to be capable
to determine which one of these two configurations is used in a given
system, so that one need not specify "--build=" to get what is desired.

---

From: Thiemo Seufer <[email-masked]>
Date: Thu, 15 May 2003 13:50:32 +0200

> -- to (n)64.  It isn't the case, indeed.

IMHO it's not particularily useful to have both of these. I assume a n64
capable system will always implement n32 also, for better performance
and less memory consumption, and the majority of applications will run
as n32. IOW, there's little need for a n64-defaulting configuration.

But IIRC we disagree about this point.

Thiemo

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Thu, 15 May 2003 14:38:45 +0200 (MET DST)

> But IIRC we disagree about this point.

 It's not about whether we agree or not -- it's about letting a user make
a choice what suits him better.  We need not force anyone to accept our
points of view -- it's one of the main advantages of free software. 

 Also I would like to allow glibc to be configured without n32 and won't
object disallowing (n)64 alternatively.  I already run kernels that
support o32 and (n)64 only (o32 is temporary, of course, until glibc
supports (n)64), so it's not true an (n)64-capable system always supports
n32. 

 BTW, you may want a program to be built as (n)64 whenever it uses mmap() 
and can operate on the so called "large files".  So there may be
significantly more programs requiring the (n)64 format than it may seem at
the first thought. 

  Maciej