me vs gas mips64 relocation

me vs gas mips64 relocation

[d p chang]

Hi there, I'm trying to figure out if i've just misconfigured
something here or if there is a real problem in gas. I did some
grovelling through the mailing list archives, but really am still
catching up.

Anyway, here at home i grabbed the current cvs binutils and configured
(i thought successfully since I only checked the assembly before the
final link and hadn't been looking at the reloc bits) it to cross
compile from macos x to mips64-linux. It appeared to be successful but
it wasn't until i had written the rest of my chipset startup logic
that I noticed a problem.

My test case looks like this:

    .text
    .comm   my_test_global, 8, 8

    LEAF(reloc_hi_test)

    ld      t0, my_test_global      ; my problem

    lui     t0, %hi(my_test_global) ; works
    addiu   t0, %lo(my_test_global)

    END(reloc_hi_test)

    .end

i compile this w/ (i only just added all the verbosity flags).

    mips64-linux-gcc  -I /Volumes/Homey/dpc/Devel/linux-2.4.17/include/asm/gcc -D__KERNEL__ -I/Volumes/Homey/dpc/Devel/linux-2.4.17/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -G 0 -mno-abicalls -fno-pic -Wa,--trap -pipe -mips4 -mmad -Wa,-march=r5231 -mlong64 -mgp64 -mfp64 -ffreestanding -mabi=n32 reloc.S -c -o reloc.o -Wa,-acdhls -v -Wa,-v -Wa,-O0 

and I get this from objdump:

    reloc.o:     file format elf32-tradbigmips

    Disassembly of section .text:

    00000000 <reloc_hi_test>:
       0:   3c0c0000        lui     t0,0x0
       4:   258c0000        addiu   t0,t0,0
                            4: R_MIPS_LO16  my_test_global
       8:   3c0c0000        lui     t0,0x0
                            8: R_MIPS_HI16  my_test_global
       c:   258c0000        addiu   t0,t0,0
                            c: R_MIPS_LO16  my_test_global

Anyway, the missing R_MIPS_HI16 relocation at offset 0 is my
problem. I had expected the two to generate the same code. am i
mistaken, did i screw something up configuring, is this a bug, or
something else?

\p

Re: me vs gas mips64 relocation

[d p chang]

d p chang <weasel@meer.net> writes:

> i compile this w/ (i only just added all the verbosity flags).
> 
>     mips64-linux-gcc  -I /Volumes/Homey/dpc/Devel/linux-2.4.17/include/asm/gcc -D__KERNEL__ -I/Volumes/Homey/dpc/Devel/linux-2.4.17/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -G 0 -mno-abicalls -fno-pic -Wa,--trap -pipe -mips4 -mmad -Wa,-march=r5231 -mlong64 -mgp64 -mfp64 -ffreestanding -mabi=n32 reloc.S -c -o reloc.o -Wa,-acdhls -v -Wa,-v -Wa,-O0 

Looking at this some more I realize that my problem is probably that
I'm lying to the compiler/assembler by claiming n32 and long64. We
would like to have 64 bit registers available to us in user space, but
enabling -mabi=64 gives an assertion in ld when it is trying to output
relocations for a .pdr section.

ideas? (other than for me to take the crack pipe out of my ass)

\p
---
I feel discomfort, therefore I am alive. --- Graham Greene

Re: me vs gas mips64 relocation

[Eric Christopher]

> ideas? (other than for me to take the crack pipe out of my ass)

You can try to help Thiemo Seufer finish n32 and n64 support in
binutils...

-eric

-- 
I will not use abbrev.

Re: me vs gas mips64 relocation

[d p chang]

Eric Christopher <echristo@redhat.com> writes:

> > ideas? (other than for me to take the crack pipe out of my ass)
> 
> You can try to help Thiemo Seufer finish n32 and n64 support in
> binutils...

Is there a todo or something that I could start w/?

\p

Re: me vs gas mips64 relocation

[Daniel Jacobowitz]

On Sat, Feb 02, 2002 at 08:47:30PM -0800, d p chang wrote:
> Eric Christopher <echristo@redhat.com> writes:
> 
> > > ideas? (other than for me to take the crack pipe out of my ass)
> > 
> > You can try to help Thiemo Seufer finish n32 and n64 support in
> > binutils...
> 
> Is there a todo or something that I could start w/?

Search for TODO in elf64-mips.c, if I recall correctly.  Among other
things PIC support is non-functional.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer