This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: mips 64-bit address generation is broken.

At Mon, 18 Feb 2002 22:55:06 +0100 (MET), Maciej W. Rozycki wrote:
> On 18 Feb 2002 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... :-(

"I sure hope it's not disabled, because it is something that people
have been using for years."

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

Actually, there's no shortage of code out there that assumes sizeof
long == sizeof pointer.  not completely portable, but in fact an
assumption that works fine for most machines, including MIPS with
-mlong64 or any of the 'good' ABIs.

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

* direct access to xkphys using pointers.

* you don't necessarily have 32-bit text / data / bss addresses.
  Consider embedded-pic, where your 32-bit binary code may in fact be
  moved to ... "anywhere" including 64-bit space.

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

not really.  you link everything into 32-bit addresses, fine.  I don't
think i've ever seen a strong need for actually putting a 64-bit
address in the .o file.  ("and a good thing, since it wouldn't work.")

But 64-bit addresses work great dynamically.

It's become "pretty fragile" recently, but it used to work pretty
well.  8-)

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

That's _so_ not true.  That assumes that nobody has done external
utilities to read the object files and 'do stuff' to them.

In fact, I can say with certainty that people have.  Different people
and a bunch of different things.  All of the code would need to be
adapted for 64-bit ELF.

And no, in at least a bunch of circumstances it can't (or couldn't
have been -- it's already written now) be made to use BFD, because the
license on BFD is not acceptable.

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

Ahh, so what you're saying is that there's going to be no future
enhancement to gcc which is worth using?  8-)

"i don't think so."

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

If you're starting a new project -- after working 64-bit alternatives
are in the binutils -- then yes, I should think you'd want to be using


(1) they're not, yet, so you can't start down that road yet.

(2) "existing projects" can still benefit from e.g. new compiler
    technology or even just simple bug fixes in later releases of
    various tools for years after the start of the project.

    In my experience, people working on something often upgrade their
    tools while they're doing it, esp. for multi-year projects, and
    especially when the tools are being improved substantially over
    the life of the project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]