Re: musl mips n64 dynamic build

[Rich Felker <dalias@libc.org>]

On Mon, Oct 19, 2015 at 02:51:12PM +0530, Mahesh Bodapati wrote:
> Hi Rich,
> 
> I have ported musl libraries for MIPS n64 ABI architecture and I have setup
> $gp as
> 
> Crt1.s:

crt1.s is obsolete and should not be used for new archs. The benefit
to you is that crt_arch.h (the new way of doing it) is a lot easier to
write. All you need to do is jump to the C entry point _start_c with
the right calling convention for a C function and the first 2 argument
slots containing the original stack pointer and a pointer to _DYNAMIC,
respectively. _start_c can be assumed to be defined in the same source
file.

> *lui           $3,%hi(%neg(%gp_rel(_start)))*
> 
> *            daddu
> $3,$3,$25                                                /* same in dlsym.s
> and pipe.s */*
> 
> *            daddiu  $gp,$3,%lo(%neg(%gp_rel(_start)))*
> 
>             ld      $4, %got_disp(main)($gp)   # Get main() ..

Jumping to main from crt1 is not valid. You need to call
__libc_start_main. But if you use crt_arch.h this part happens
automatically for you.

> I didn’t setup $gp as in MIPS o32 ABI as we shouldn’t use _*gp*_disp for
> setting up $gp
> 
> “The special symbol name _gp_disp, used for relocating the calculation of gp
> on entry to a DSO in 32-bit files, is
> 
> not supported in ELF-64 or in the new 32-bit ABI. Instead, these relocations
> should be composed with
> 
> R_MIPS_GPREL applied to an explicit symbol for the entry point of the
> subprogram

I'm not sure what document you're quoting, but sometimes these things
express assumptions about a particular usage case that don't apply to
what musl is doing. But you should be able to avoid writing this code
anyway.

> involves loading the difference between the entry
> 
> address of a subprogram s and the runtime gp for establishing gp:
> 
> A: lui rx, %hi(%neg(%gp_rel(s)))# load high part of diff
> 
> B: daddiu rx, rx, %lo(%neg(%gp_rel(s)))# add low part
> 
> C: dadd gp, t9, rx # add to entry address  “
> 
> 
> 
> Now I am able to build dynamic n64 musl libraries and n64 dynamic
> application but it’s not showing any relocation with it
> 
> and execution of application is giving errors like “unsupported relocation
> type errors”

Did you make a reloc.h defining the relocation types needed for mips
n64 and mapping them to the generic-reloc names musl uses for them?
See the existing arch/*/reloc.h files. Without these being defined
directly the dynamic linker will not be able to process the
relocations it finds in itself or in the main program or other
libraries.

But without a working crt_arch.h I'm surprised the dynamic linker can
even start at all. Are you sure you're not using the mips32 dynamic
linker? Look at the program headers (using readelf -l) for INTERP.

> $ objdump -R main
> 
> 
> 
> a.out:     file format elf64-tradbigmips
> 
> 
> 
> DYNAMIC RELOCATION RECORDS (none)
> 
> 
> 
> $ ./main
> 
> Error relocating libc.so: unsupported relocation type 482431
> 
> Error relocating libc.so: unsupported relocation type 482687
> 
> Error relocating libc.so: unsupported relocation type 482943
> 
> Error relocating libc.so: unsupported relocation type 483199
> 
> ;
> 
> ;
> 
> ;
> 
> Segmentation fault
> 
> 
> 
> So Can you suggest how can I resolve these errors? I am thinking like
> either doing changes in do_mips_reloc(),do_relocs() functions in musl
> sources or in usage of relocations.

OK, I see what's going wrong here. The invalid relocation types are
being produced by this line in do_mips_relocs:

	rel[1] = sym-p->syms << 8 | R_MIPS_JUMP_SLOT;

That produces a relocation in the elf32 encoding, because I just
assumes mips is elf32 when I wrote it. I believe the 64-bit version
should be:

	rel[1] = sym-p->syms << 32 | R_MIPS_JUMP_SLOT;

Try just making that change and see if it works. If so we can work on
making a clean conditional for 32- vs 64-bit here later.

Rich