Subject: recent binutils and mips64-linux

From: Daniel Jacobowitz <[email-masked]>
Date: Thu, 18 Sep 2003 17:27:27 -0400

I'm sure this has been discussed already...

The Linux kernel currently uses among other things, -Wa,-32,-mgp64.  The
point is to use 32-bit ELF and 64-bit instructions.  But nowadays binutils
requires that the ABI explicitly match the width of GP registers.

Can gas still do ELF32 in with 64-bit registers?  If so, what the heck is
the command-line magic?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

---

From: Eric Christopher <[email-masked]>
Date: Thu, 18 Sep 2003 19:58:00 -0700

> Can gas still do ELF32 in with 64-bit registers?  If so, what the heck is

Discussed on irc :)

mips-linux-gcc -mabi=32 -march=64bitarch is my suggestion.

otherwise, -mabi=o64 is o32 extended to 64-bit registers.

-eric

-- 
Eric Christopher <[email-masked]>

---

From: Atsushi Nemoto <[email-masked]>
Date: Fri, 19 Sep 2003 12:29:40 +0900 (JST)

>>>>> On Thu, 18 Sep 2003 19:58:00 -0700, Eric Christopher <[email-masked]> said:
echristo> mips-linux-gcc -mabi=32 -march=64bitarch is my suggestion.

But mips64 kernel assumes that the kernel itself is compiled with
"-mabi=64".  For example, some asm routines pass more than 4 arguments
via aN registers.

---
Atsushi Nemoto

---

From: Daniel Jacobowitz <[email-masked]>
Date: Thu, 18 Sep 2003 23:28:01 -0400

> "-mabi=64".  For example, some asm routines pass more than 4 arguments

I was able to build using -mabi=64 -Wa,-mabi=o64.  There are... some
issues... but I think that's just this board port.

---

From: Eric Christopher <[email-masked]>
Date: Thu, 18 Sep 2003 22:39:45 -0700

> "-mabi=64".  For example, some asm routines pass more than 4 arguments

Yes, but then you aren't abi compliant are you? If you want n64 then say
n64. If you want o32 extended to 64-bit registers then use o64.

-eric

---

From: Atsushi Nemoto <[email-masked]>
Date: Fri, 19 Sep 2003 16:23:01 +0900 (JST)

>>>>> On Thu, 18 Sep 2003 23:28:01 -0400, Daniel Jacobowitz <[email-masked]> said:
dan> I was able to build using -mabi=64 -Wa,-mabi=o64.  There
dan> are... some issues... but I think that's just this board port.

The "-Wa,-mabi=o64" works good for me.  Without this option, I had to
use ld.script.elf64 and convert vmlinux to elf32-tradlittlemips using
objcopy if I wanted to use newer binutils.  Thanks!!

---
Atsushi Nemoto

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Fri, 19 Sep 2003 14:52:35 +0200 (MET DST)

> n64. If you want o32 extended to 64-bit registers then use o64.

 I think "-mabi=64" is OK (I use it for over a year now) and for those
worried of every byte of precious memory, "-mabi=n32 -mlong64" might be
the right long-term answer (although it might require verifying if tools
handle it right).  Given the experimental state of the 64-bit kernel it
should be OK to be less forgiving on a requirement for recent tools. 

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

---

From: Eric Christopher <[email-masked]>
Date: Fri, 19 Sep 2003 09:20:20 -0700

> should be OK to be less forgiving on a requirement for recent tools. 

OK as in "it works for me", and OK as in "this is the correct usage" are
two different things. I believe that for a 64-bit kernel either -mabi=64
or -mabi=n32 (-mlong64) are the right long term answer, part of Daniel's
problem was that his bootloader couldn't deal with ELF64.

-eric

---

From: Thiemo Seufer <[email-masked]>
Date: Fri, 19 Sep 2003 18:41:19 +0200

Eric Christopher wrote:
> or -mabi=n32 (-mlong64) are the right long term answer,

A third answer is to add a -msign-extend-addresses switch in the assembler.
Together with -mabi=64 this would produce optimized ELF64 output.

> part of Daniel's

Well, implementing an ELF64 bootloader ins't that hard. :-)

Thiemo

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Fri, 19 Sep 2003 18:42:11 +0200 (MET DST)

> OK as in "it works for me", and OK as in "this is the correct usage" are

 Well, my "OK" is of both kinds. 8-) 

> problem was that his bootloader couldn't deal with ELF64.

 I've successfully converted ELF64 Linux images to o32 ELF32, with
`objcopy' and then to COFF even, with `elf2ecoff' (provided with the Linux
sources).  The resulting COFF image used to work with the DECstation's
firmware.  I suppose the intermediate ELF32 one would work with
ELF-capable firmware, too.  Of course I had to make sure the addresses
seen by the firmware in the file headers fit the 32-bit address space
(KSEG0, actually; KSEG1 might work, too).

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Fri, 19 Sep 2003 18:46:31 +0200 (MET DST)

> Together with -mabi=64 this would produce optimized ELF64 output.

 Hmm, what do you exactly mean -- is that what I am worrying about?

> Well, implementing an ELF64 bootloader ins't that hard. :-)

 That depends on how hard it's to replace some firmware.  Using a
secondary boot loader is not always feasible, either.

---

From: Thiemo Seufer <[email-masked]>
Date: Fri, 19 Sep 2003 18:57:47 +0200

Maciej W. Rozycki wrote:
[snip]
> ELF-capable firmware, too.

I booted the ELF32 file via the delo bootloader and it worked.

Thiemo

---

From: Thiemo Seufer <[email-masked]>
Date: Fri, 19 Sep 2003 19:08:25 +0200

>  Hmm, what do you exactly mean -- is that what I am worrying about?

The idea is to use the assembler's 32bit macro expansions for addresses.
This reduces the .text size of a n64 kernel and improves the performance,
without tricks like -Wa,32.

Thiemo

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Fri, 19 Sep 2003 19:19:38 +0200 (MET DST)

> The idea is to use the assembler's 32bit macro expansions for addresses.

 So it is...

> without tricks like -Wa,32.

 What if the final link leads to segments being mapped outside the 32-bit
address range?  We won't know about it when assembling.

 If the idea were to be implemented, there should be a flag added to the
header of object files that would forbid the linker to map addresses
outside the 32-bit range.

---

From: Thiemo Seufer <[email-masked]>
Date: Fri, 19 Sep 2003 19:40:39 +0200

> address range?  We won't know about it when assembling.

Then the resulting code is broken. It's the programmers responsibility
to care about it. IMHO that's not a problem, this feature is only
useful for kernels, and the tricks currently done there are worse.

> outside the 32-bit range.

Please don't add any header flag. An additional (.note?) section would
be nice, but is not a priority for me.

Thiemo

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Fri, 19 Sep 2003 20:14:45 +0200 (MET DST)

> to care about it. IMHO that's not a problem, this feature is only

 Sure, but some kind of aid, perhaps conditional, from tools would be
good.  The linker is already unconditionally picky about certain
properties of object files, e.g. it won't link a PIC and a PDC object
together, even if there are no relocations in them.  One could say it's a
programmer's responsibility, too. 

> useful for kernels, and the tricks currently done there are worse.

 No doubt.

> be nice, but is not a priority for me.

 Well, I might not really care of something I'm not going to use, but we
should try to assure some level of engineering quality whenever possible.
A flag vs a special section is alike to me.

---

From: David Kesselring <[email-masked]>
Date: Fri, 19 Sep 2003 14:28:49 -0400 (EDT)

I've been trying to follow this discussion but I don't see the consensus.
Probably from my inexperience. Can someone summarize what works now, as
opposed to what should be done? Is
the solution the same for the 2.4kernel/gcc2.95 and the 2.6kernel/gcc3+?
Also are all of these comments appicable to little and big endian systems?
Thanks,
David Kesselring

> be nice, but is not a priority for me.

David Kesselring
Atmel MMC
[email-masked]
919-462-6587

---

From: Alexandre Oliva <[email-masked]>
Date: 22 Sep 2003 18:26:40 -0300

> A third answer is to add a -msign-extend-addresses switch in the assembler.

In what sense is this different from -Wa,-mabi=n32 ?

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

---

From: Daniel Jacobowitz <[email-masked]>
Date: Mon, 22 Sep 2003 17:31:33 -0400

> In what sense is this different from -Wa,-mabi=n32 ?

GDB gets the idea that you've got n64 code instead of o32 or n32 or
whatever code.  It transfers 64-bit data to the remote stub, et cetera.

---

From: Thiemo Seufer <[email-masked]>
Date: Tue, 23 Sep 2003 01:39:52 +0200

> In what sense is this different from -Wa,-mabi=n32 ?

ELF64 instead of ELF32.

Thiemo

---

From: Eric Christopher <[email-masked]>
Date: Mon, 22 Sep 2003 18:21:46 -0700

> > In what sense is this different from -Wa,-mabi=n32 ?

objcopy?

-eric

---

From: Thiemo Seufer <[email-masked]>
Date: Tue, 23 Sep 2003 10:14:47 +0200

> > > In what sense is this different from -Wa,-mabi=n32 ?

You mean, let gcc generate n64 code, stuff it in n32 objects, and
objcopy it back to n64? Well, it may work, but it looks more like
a test of binutils sign-extension handling than a straightforward
way of creating kernels to me.

Besides, as soon as gcc handles 64bit expansions itself we need
such an option anyway.

Thiemo

---

From: Eric Christopher <[email-masked]>
Date: Tue, 23 Sep 2003 11:01:11 -0700

> Besides, as soon as gcc handles 64bit expansions itself we need

I'm still trying to figure out why you are going through such weird
contortions at all. I understand not having an elf64 loader. That's what
the objcopy comment was for, everything else I don't understand. Why not
compile for the abi you want?

-eric

---

From: Daniel Jacobowitz <[email-masked]>
Date: Tue, 23 Sep 2003 14:16:59 -0400

> compile for the abi you want?

Compare the optimal way to load an address into a register when you
have a full 64-bit address space and when you know that addresses are
sign extended.  I'm told it saves over 100K of code.

---

From: "Zack Weinberg" <[email-masked]>
Date: Tue, 23 Sep 2003 12:45:36 -0700

> sign extended.  I'm told it saves over 100K of code.

Maybe what you really want is an -mdata-model=kernel switch (or some
such spelling) that tells gcc to do the right thing in the first
place?

zw

---

From: Daniel Jacobowitz <[email-masked]>
Date: Tue, 23 Sep 2003 15:56:39 -0400

> such spelling) that tells gcc to do the right thing in the first

GCC should get a switch to do this.  But GCC doesn't (does 3.4 yet?)
emit these itself anyway.  Binutils expands them from the dla macro.

---

From: Thiemo Seufer <[email-masked]>
Date: Tue, 23 Sep 2003 22:03:37 +0200

Zack Weinberg wrote:
> such spelling)

Well, an ELF64 kernel loaded in the 64bit address space is also legal,
and desireable on some (bigger) hardware. Btw, it would have to be
-mtext-model=kernel, the data is the same. :-)

> that tells gcc to do the right thing in the first place?

Gcc still generates MIPS assembler macros, so such a switch would
do nothing yet. Gcc should be changed to do the expansion itself
(and improve code quality by that), but that's a much larger task.

Thiemo

---

From: "Zack Weinberg" <[email-masked]>
Date: Tue, 23 Sep 2003 13:06:03 -0700

> -mtext-model=kernel, the data is the same. :-)

Well, you wouldn't compile such a kernel with that switch.  Maybe
spelling it -mtext-model=kseg0 would be more descriptive.

> (and improve code quality by that), but that's a much larger task.

Gcc can at least pass the setting along to the assembler (which would
have to grow such an option as well, either as a command line switch
or (preferred) a .directive).

zw

---

From: Thiemo Seufer <[email-masked]>
Date: Tue, 23 Sep 2003 22:18:55 +0200

Zack Weinberg wrote:
[snip]
> or (preferred) a .directive).

Hand-coded assembly will need the command line switch, as the same
file should work for both models if possible.

Thiemo

---

From: Eric Christopher <[email-masked]>
Date: Tue, 23 Sep 2003 13:28:03 -0700

> (and improve code quality by that), but that's a much larger task.

And is done in mainline.

.set nomacro, .set noreorder provided you have a gas that can deal with
it on the function level.

-eric