GNU linker on mips

GNU linker on mips

[Koundinya.K]

Hello Ian,
	Thanks for the quick response. Yes I have been doing some debugging ( not 
any programming so far ....).

In the mips-elf32.c (bfd) I changed back the SGI_COMPAT to 0 ( which I had 
changed it to 1)

I have a utility called truss  (trace system calls and signals). 

I wrote a test program (t.c).and then I id 2 tests...

1) compiled using the native ld and GNU assembler 

Result -- No problem (as usual)

$gcc -v t.c -o tt

$truss tt

execve("./tt", 0x7FFFBAF0, 0x7FFFBAF8)  argc = 1
open("/usr/lib/libc.so.patch", O_RDONLY, 01)    = 3
fxstat(2, 3, 0x7FFFB6E8)                        = 0
mmap(0x00000000, 8192, PROT_READ, MAP_SHARED, 3, 0) = 0x400C0000
mmap(0x00000000, 109920, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40100000
mmap(0x4011A000, 3376, PROT_READ|PROT_WRITE|PROT_EXEC, 
MAP_PRIVATE|MAP_FIXED, 3,
 40960) = 0x4011A000
munmap(0x4010C000, 57344)                       = 0
close(3)                                        = 0
ioctl(1, TCGETA, 0x7FFFB91C)                    Err#25 ENOTTY
fxstat(2, 1, 0x7FFFB964)                        = 0
brk(0x004147D0)                                 = 0
Hello....
write(1, " H e l l o . . . .\n", 10)            = 10
_exit(10)


2)compiled using the GNU ld and gnu assembler

RESULT -- Problem -- 

dynamic linker: ./tt: unidentifiable procedure reference (address = 
0x40062cd8)
Killed

$gcc -v t.c -o tt
$truss tt

execve("./tt", 0x7FFFBAF8, 0x7FFFBB00)  argc = 1
open("/usr/lib/libc.so.patch", O_RDONLY, 01)    = 3
fxstat(2, 3, 0x7FFFB6E8)                        = 0
mmap(0x00000000, 8192, PROT_READ, MAP_SHARED, 3, 0) = 0x400C0000
mmap(0x00000000, 109920, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40100000
mmap(0x4011A000, 3376, PROT_READ|PROT_WRITE|PROT_EXEC, 
MAP_PRIVATE|MAP_FIXED, 3,
 40960) = 0x4011A000
munmap(0x4010C000, 57344)                       = 0
close(3)                                        = 0
ioctl(1, TCGETA, 0x7FFFB91C)                    Err#25 ENOTTY
fxstat(2, 1, 0x7FFFB964)                        = 0
brk(0x100040A0)                                 = 0
dynamic linker: tt: unidentifiable procedure reference (address = 0x40062cd8)
write(2, " d y n a m i c   l i n k".., 78)      = 78
getpid()                                        = 18404  [ 18403 ]
        *** process killed ***

-----------------------------------------------------------------------------
-

Does this give any pointers to the problem...

Thanks for all the help and information in advance.

With best regards

Koundinya

P.S:
I need to configure as (rather I have added this in my configure.tgt

mips-dde-sysv4*)        targ_emul=elf32bsmip ;;	

My native ld sets the ENTRY to __start as on IRIX Systems.

Re: GNU linker on mips

[ralf]

On Mon, Feb 01, 1999 at 11:57:54AM +0530, Koundinya.K wrote:


> My native ld sets the ENTRY to __start as on IRIX Systems.

Can anybody explain why IRIX uses a non-zero value for __start?  That
triggered quite a number of bugs in basically every piece of software that
tries to load ELF binaries into memory ...  So far we're just doing the same
thing for mips*-*-linux but there not really a good reason.

  Ralf

Re: GNU linker on mips

[Ian Lance Taylor]

   Date: Tue, 2 Feb 1999 11:45:43 +0100
   From: ralf@uni-koblenz.de

   On Mon, Feb 01, 1999 at 11:57:54AM +0530, Koundinya.K wrote:

   > My native ld sets the ENTRY to __start as on IRIX Systems.

   Can anybody explain why IRIX uses a non-zero value for __start?  That
   triggered quite a number of bugs in basically every piece of software that
   tries to load ELF binaries into memory ...  So far we're just doing the same
   thing for mips*-*-linux but there not really a good reason.

I don't know of any system which uses a zero value for __start.  Most
systems protect the zero page to catch null pointer dereferences.  Why
do you expect __start to be zero?  What sorts of problems are you
seeing?

Ian

Re: GNU linker on mips

[ralf]

On Tue, Feb 02, 1999 at 09:37:17PM -0500, Ian Lance Taylor wrote:

> I don't know of any system which uses a zero value for __start.  Most
> systems protect the zero page to catch null pointer dereferences.  Why
> do you expect __start to be zero?  What sorts of problems are you
> seeing?

Sorry, braino on my side.  I meant SHLIB_TEXT_START_ADDR, not __start.  MIPS
systems typically use 0x5ffe0000, not zero and that triggered kernel bugs,
glibc bugs and some undesireable behaviour in the Linux kernel, glibc dynamic
linker and others I forgot.  It did not trigger any bfd / gas / binutils bugs.

  Ralf

Re: GNU linker on mips

[Ian Lance Taylor]

   Date: Wed, 3 Feb 1999 13:03:47 +0100
   From: ralf@uni-koblenz.de

   On Tue, Feb 02, 1999 at 09:37:17PM -0500, Ian Lance Taylor wrote:

   > I don't know of any system which uses a zero value for __start.  Most
   > systems protect the zero page to catch null pointer dereferences.  Why
   > do you expect __start to be zero?  What sorts of problems are you
   > seeing?

   Sorry, braino on my side.  I meant SHLIB_TEXT_START_ADDR, not __start.  MIPS
   systems typically use 0x5ffe0000, not zero and that triggered kernel bugs,
   glibc bugs and some undesireable behaviour in the Linux kernel, glibc dynamic
   linker and others I forgot.  It did not trigger any bfd / gas / binutils bugs.

Ah.  I don't know why SHLIB_TEXT_START_ADDR should be anything other
than zero.  It seems to me that making it zero is a bit more natural
for the RELATIVE relocs, but I don't think MIPS ELF has a RELATIVE
reloc anyhow, and of course it shouldn't really matter anyhow.

If it is more convenient for the Linux kernel to make
SHLIB_TEXT_START_ADDR 0 for MIPS GNU/Linux, then I can't see any
reason not to do it.

Ian