This is the mail archive of the binutils@sources.redhat.com 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]

Re: [PATCH] Fix distinction of 32/64bit addresses in MIPS gas


On Fri, Aug 31, 2001 at 12:41:37PM -0700, cgd@broadcom.com wrote:
> ica2_ts@csv.ica.uni-stuttgart.de ("Thiemo Seufer") writes:
> > Can you give a example where R_MIPS_64 is actually needed instead
> > of R_MIPS_32? If the output is truncated I can't see why R_MIPS_32
> > (possibly with tweaked content) insn't enough.
> 
> cat > foo.c << __EOF__
> extern int foo;
> 
> int *bar = &foo;
> __EOF
> mips-elf-gcc -mips4 -mlong64 -c foo.c
> 
> 
> i believe that should be sufficient.  (certainly, it does the trick
> here with both our mips-linux tools and mips-elf-variant tools... 8-)
> 
> yes, i know that the pointer is going to be constrainted to being a
> sign-extended 32-bit value, but neither the compiler or any assembly
> code that uses it needs to know that (or should).  As far as they're
> concerned, pointers are 64-bit values and they're loaded with ld, etc.

Why do you need R_MIPS_64 for that?

> 
> yes, there's code that actually uses this.  why?  it's really nice to
> have code that is linked into a 32-bit address space, but can have
> 'usable' 64-bit pointers in C code.  e.g. code that lives at the boot
> vector, but wants to address data in xkphys...  One could use 64-bit
> ELF for these programs, but that support is really new (does it even
> work completely yet?), and, really, there's no reason for people doing
> this to _want_ to switch to 64-bit ELF so why do it?

What is the 32bit address of `foo'?


H.J.


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