recent binutils and mips64-linux

recent binutils and mips64-linux

[Daniel Jacobowitz]

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

Re: recent binutils and mips64-linux

[Eric Christopher]

On Thu, 2003-09-18 at 14:27, Daniel Jacobowitz wrote:
> 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?

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 <echristo@redhat.com>

Re: recent binutils and mips64-linux

[Daniel Jacobowitz]

On Fri, Sep 19, 2003 at 12:29:40PM +0900, Atsushi Nemoto wrote:
> >>>>> On Thu, 18 Sep 2003 19:58:00 -0700, Eric Christopher <echristo@redhat.com> 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.

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

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: recent binutils and mips64-linux

[Atsushi Nemoto]

>>>>> On Thu, 18 Sep 2003 19:58:00 -0700, Eric Christopher <echristo@redhat.com> 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

Re: recent binutils and mips64-linux

[Eric Christopher]

On Thu, 2003-09-18 at 20:29, Atsushi Nemoto wrote:
> >>>>> On Thu, 18 Sep 2003 19:58:00 -0700, Eric Christopher <echristo@redhat.com> 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.

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

-- 
Eric Christopher <echristo@redhat.com>

Re: recent binutils and mips64-linux

[Atsushi Nemoto]

>>>>> On Thu, 18 Sep 2003 23:28:01 -0400, Daniel Jacobowitz <dan@debian.org> 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

Re: recent binutils and mips64-linux

[Maciej W. Rozycki]

On Thu, 18 Sep 2003, Eric Christopher wrote:

> > 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.
> 
> 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.

 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: macro@ds2.pg.gda.pl, PGP key available        +

Re: recent binutils and mips64-linux

[Eric Christopher]

On Fri, 2003-09-19 at 05:52, Maciej W. Rozycki wrote:
> On Thu, 18 Sep 2003, Eric Christopher wrote:
> 
> > > 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.
> > 
> > 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.
> 
>  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. 

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

-- 
Eric Christopher <echristo@redhat.com>

Re: recent binutils and mips64-linux

[Thiemo Seufer]

Eric Christopher wrote:
> On Fri, 2003-09-19 at 05:52, Maciej W. Rozycki wrote:
> > On Thu, 18 Sep 2003, Eric Christopher wrote:
> > 
> > > > 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.
> > > 
> > > 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.
> > 
> >  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. 
> 
> 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,

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
> problem was that his bootloader couldn't deal with ELF64.

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


Thiemo

Re: recent binutils and mips64-linux

[Maciej W. Rozycki]

On Fri, 19 Sep 2003, Eric Christopher wrote:

> >  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. 
> 
> 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-) 

> 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.

 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). 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: recent binutils and mips64-linux

[Maciej W. Rozycki]

On Fri, 19 Sep 2003, Thiemo Seufer wrote:

> > 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,
> 
> A third answer is to add a -msign-extend-addresses switch in the assembler.
> Together with -mabi=64 this would produce optimized ELF64 output.

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

> > part of Daniel's
> > problem was that his bootloader couldn't deal with ELF64.
> 
> 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.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: recent binutils and mips64-linux

[Thiemo Seufer]

Maciej W. Rozycki wrote:
[snip]
> > 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.
> 
>  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.

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


Thiemo

Re: recent binutils and mips64-linux

[Thiemo Seufer]

Maciej W. Rozycki wrote:
> On Fri, 19 Sep 2003, Thiemo Seufer wrote:
> 
> > > 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,
> > 
> > A third answer is to add a -msign-extend-addresses switch in the assembler.
> > Together with -mabi=64 this would produce optimized ELF64 output.
> 
>  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

Re: recent binutils and mips64-linux

[Maciej W. Rozycki]

On Fri, 19 Sep 2003, Thiemo Seufer wrote:

> > > A third answer is to add a -msign-extend-addresses switch in the assembler.
> > > Together with -mabi=64 this would produce optimized ELF64 output.
> > 
> >  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.

 So it is...

> This reduces the .text size of a n64 kernel and improves the performance,
> 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.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: recent binutils and mips64-linux

[Thiemo Seufer]

Maciej W. Rozycki wrote:
> On Fri, 19 Sep 2003, Thiemo Seufer wrote:
> 
> > > > A third answer is to add a -msign-extend-addresses switch in the assembler.
> > > > Together with -mabi=64 this would produce optimized ELF64 output.
> > > 
> > >  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.
> 
>  So it is...
> 
> > This reduces the .text size of a n64 kernel and improves the performance,
> > 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.

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.

>  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.

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


Thiemo

Re: recent binutils and mips64-linux

[Maciej W. Rozycki]

On Fri, 19 Sep 2003, Thiemo Seufer wrote:

> >  What if the final link leads to segments being mapped outside the 32-bit
> > 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

 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.

> >  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.
> 
> Please don't add any header flag. An additional (.note?) section would
> 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.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: recent binutils and mips64-linux

[David Kesselring]

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

On Fri, 19 Sep 2003, Thiemo Seufer wrote:

> Maciej W. Rozycki wrote:
> > On Fri, 19 Sep 2003, Thiemo Seufer wrote:
> >
> > > > > A third answer is to add a -msign-extend-addresses switch in the assembler.
> > > > > Together with -mabi=64 this would produce optimized ELF64 output.
> > > >
> > > >  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.
> >
> >  So it is...
> >
> > > This reduces the .text size of a n64 kernel and improves the performance,
> > > 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.
>
> 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.
>
> >  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.
>
> Please don't add any header flag. An additional (.note?) section would
> be nice, but is not a priority for me.
>
>
> Thiemo
>
>

David Kesselring
Atmel MMC
dkesselr@mmc.atmel.com
919-462-6587

Re: recent binutils and mips64-linux

[Alexandre Oliva]

On Sep 19, 2003, Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de> wrote:

> 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

Re: recent binutils and mips64-linux

[Daniel Jacobowitz]

On Mon, Sep 22, 2003 at 06:26:40PM -0300, Alexandre Oliva wrote:
> On Sep 19, 2003, Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de> wrote:
> 
> > A third answer is to add a -msign-extend-addresses switch in the assembler.
> 
> 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.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: recent binutils and mips64-linux

[Thiemo Seufer]

Alexandre Oliva wrote:
> On Sep 19, 2003, Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de> wrote:
> 
> > A third answer is to add a -msign-extend-addresses switch in the assembler.
> 
> In what sense is this different from -Wa,-mabi=n32 ?

ELF64 instead of ELF32.


Thiemo

Re: recent binutils and mips64-linux

[Eric Christopher]

On Mon, 2003-09-22 at 16:39, Thiemo Seufer wrote:
> Alexandre Oliva wrote:
> > On Sep 19, 2003, Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de> wrote:
> > 
> > > A third answer is to add a -msign-extend-addresses switch in the assembler.
> > 
> > In what sense is this different from -Wa,-mabi=n32 ?
> 
> ELF64 instead of ELF32.

objcopy?

-eric

-- 
Eric Christopher <echristo@redhat.com>

Re: recent binutils and mips64-linux

[Thiemo Seufer]

Eric Christopher wrote:
> On Mon, 2003-09-22 at 16:39, Thiemo Seufer wrote:
> > Alexandre Oliva wrote:
> > > On Sep 19, 2003, Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de> wrote:
> > > 
> > > > A third answer is to add a -msign-extend-addresses switch in the assembler.
> > > 
> > > In what sense is this different from -Wa,-mabi=n32 ?
> > 
> > ELF64 instead of ELF32.
> 
> objcopy?

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

Re: recent binutils and mips64-linux

[Eric Christopher]

> > 
> > objcopy?
> 
> 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.

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

-- 
Eric Christopher <echristo@redhat.com>

Re: recent binutils and mips64-linux

[Daniel Jacobowitz]

On Tue, Sep 23, 2003 at 11:01:11AM -0700, Eric Christopher wrote:
> 
> > > 
> > > objcopy?
> > 
> > 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.
> 
> 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?

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.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: recent binutils and mips64-linux

[Zack Weinberg]

Daniel Jacobowitz <dan@debian.org> writes:

> On Tue, Sep 23, 2003 at 11:01:11AM -0700, Eric Christopher wrote:
>> 
>> 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?
>
> 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.

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

Re: recent binutils and mips64-linux

[Daniel Jacobowitz]

On Tue, Sep 23, 2003 at 12:45:36PM -0700, Zack Weinberg wrote:
> Daniel Jacobowitz <dan@debian.org> writes:
> 
> > On Tue, Sep 23, 2003 at 11:01:11AM -0700, Eric Christopher wrote:
> >> 
> >> 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?
> >
> > 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.
> 
> 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?

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.


-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: recent binutils and mips64-linux

[Thiemo Seufer]

Zack Weinberg wrote:
> Daniel Jacobowitz <dan@debian.org> writes:
> 
> > On Tue, Sep 23, 2003 at 11:01:11AM -0700, Eric Christopher wrote:
> >> 
> >> 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?
> >
> > 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.
> 
> Maybe what you really want is an -mdata-model=kernel switch (or some
> 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

Re: recent binutils and mips64-linux

[Zack Weinberg]

Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de> writes:

> Zack Weinberg wrote:
>> 
>> Maybe what you really want is an -mdata-model=kernel switch (or some
>> 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. :-)

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

>> 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.

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

Re: recent binutils and mips64-linux

[Thiemo Seufer]

Zack Weinberg wrote:
[snip]
> 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).

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


Thiemo

Re: recent binutils and mips64-linux

[Eric Christopher]

> > 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.

And is done in mainline.

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

-eric

-- 
Eric Christopher <echristo@redhat.com>