This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: mips 64-bit address generation is broken.
- From: cgd at broadcom dot com
- To: "Maciej W. Rozycki" <macro at ds2 dot pg dot gda dot pl>
- Cc: ica2_ts at csv dot ica dot uni-stuttgart dot de,binutils at sources dot redhat dot com
- Date: 18 Feb 2002 14:23:39 -0800
- Subject: Re: mips 64-bit address generation is broken.
- References: <Pine.GSO.3.96.1020218220712.13485S-100000@delta.ds2.pg.gda.pl>
At Mon, 18 Feb 2002 22:55:06 +0100 (MET), Maciej W. Rozycki wrote:
> 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... :-(
"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.
Indeed.
> 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
them.
But:
(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.
cgd