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