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

[cgd at broadcom dot com]

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.

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?



chris