Re: mips 64-bit address generation is broken.

["Maciej W. Rozycki" <macro at ds2 dot pg dot gda dot pl>]

On 18 Feb 2002 cgd@broadcom.com wrote:

> >  That is absolutely fine.  As I already stated this is the 32-bit mode
> > (addressing mode, of course, as that's what matters to BFD) with 64-bit
> > ALU.  Nothing broken here, except 64-bit addressing can't work (but isn't
> > supposed to, otherwise the 64-bit mode would be chosen).
> 
> -mlong64 == 64-bit longs and pointers.

 I assumed "-mlong64" merely means 64-bit longs (IOW, the 64-bit ALU). 
Using 64-bit pointers for the 32-bit mode should be disabled ASAP.  It's
more broken I assumed, sigh... :-(

> 64-bit addressing had better work properly if you have 64-bit
> pointers.  8-)

 Of course, but 32-bit pointers will work equally well with 64-bit longs.

> And, use the sllv's to chop off the top bits of the addresses?
> 
> "no, thank you!  There were valid bits there."

 Weird, so basically you want to have a 32-bit .text + .data + .bss
(static) address space plus a 64-bit stack + heap (dynamic) one, right?
What advantages such a setup has?  Certainly you don't save space as you
can do with 32-bit pointers.

> >  Nope, at least for me.  Basically because "a 32-bit file" mean "a 32-bit
> > wide address".  Plain and simple.
> 
> Alas, there are a whole bunch of people using binutils and gcc for
> whom that is not true.

 Still "a 32-bit file" means "a 32-bit wide address" (I mean in practice) 
even if certain 64-bit addresses seem to work.  A program will break if a
static symbol with a true 64-bit address gets placed in a 32-bit file.  If
things now work then it's a pretty fragile setup. 

> You cannot completely ignore their use of the tools -- they've been
> using them that way for a Long Time.
> 
> Go back and read the example I provided.  Using "mips64-elf-gcc
> -mlong64", that's valid code and should not abort, and currently will
> be placed in a 32-bit ELF file.

 Sure -- it's my assumption about "-mlong64" that was wrong.

> Yes there is:
> 
> (1) does it actually _work_ right?  My personal experiences indicate
>     maybe not.  Reading the to-do list in bfd/elf64-mips.c, it says
>     that it doesn't support all of the stuff needed for embedded
>     development use (embedded-pic).

 I can't test it sorry.  I'll probably be able to test mips64el-linux in a
not so distant future, but that means PIC and the SysV ABI, which are not
suitable for embedded code, AFAIK.  Hopefully someone will be able to do
such tests. 

> (2) Everybody who's been doing this for years has _what_
>     infrastructure built around the existing object formats?

 Hmm, what else is needed between gcc and binutils?  If both gcc and
binutils generate correct code then there should be no problems with
switching the formats.  At most you need to s/elf32/elf64/g if you use
custom ld scripts. 

> >  As a last resort, you may always `objcopy' ELF64 statically linked final
> > executables to ELF32 if some broken firmware or whatever requires it.
> > Addresses in ELF file and program headers will get truncated, obviously,
> > and you'll have to handle it somehow within your environment. 
> 
> Which means modifying makefiles, making sure that the result can
> actually be expressed in elf32, etc.

 Makefile modifications should be minimal or none at all.  As to
expressing the result in ELF32 -- you need to check it now too.  Address
truncation may happen at any moment.  It's even more likely at the linking
stage, when calculations are performed.  When you have a final executable,
you may lose bits in ELF headers only -- file contents are safe as are
already fully relocated.  Anyway the resulting ELF32 file should be
identical to the one that is generated now. 

> No, from where I sit, it's really not acceptable to break the only
> alternative that embedded developers have had for years...

 Sure, but:

1. You need not upgrade tools at all if what you currently have works
fine.  For current needs just use whatever suits them best.

2. How about testing alternatives?  If nobody tests them, they will never
get fixed appropriately and the cumulated breakage will propagate forever. 
Or until the code is rewritten properly from scratch.  You may base new
project upon sane assumptions, can't you?

 OK, so let the Thiemo's "dla"/"la" patch go in (to 2.12 as well) as a
minimal safety check and then we should work to make sure ELF64 is not
worse than ELF32 for MIPS.  Then we may start to clean up accumulated
garbage gradually.  I will definitely look into elf64-mips.c reasonably
soon (probably this year ;-) ).  Agreed? 

  Maciej

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