From mboxrd@z Thu Jan 1 00:00:00 1970 From: "H . J . Lu" To: cgd@broadcom.com Cc: ica2_ts@csv.ica.uni-stuttgart.de, binutils@sources.redhat.com Subject: Re: [PATCH] Fix distinction of 32/64bit addresses in MIPS gas Date: Fri, 31 Aug 2001 14:31:00 -0000 Message-id: <20010831143107.A4532@lucon.org> References: <20010825032615.E309@rembrandt.csv.ica.uni-stuttgart.de> <20010831181657.A17249@rembrandt.csv.ica.uni-stuttgart.de> <200108311711.KAA19709@geoffk.org> <20010831193107.A10362@rembrandt.csv.ica.uni-stuttgart.de> <20010831204556.C17249@rembrandt.csv.ica.uni-stuttgart.de> X-SW-Source: 2001-08/msg00735.html 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.