GNU Linker and mips...

GNU Linker and mips...

[Koundinya.K]

Hi,
	Here is some info on my debugging the GNU linker with gdb as suggested.

I just took the small test program of "hello" to avoid those thousands of 
assembly instructions. 

As you know the output that I get is 

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

Now what is there at this location and from where is this message coming...

O.K From the assembly I could see the following...

0x40062cd8 [_exithandle+0x6c]:	lw %t0,0(%s)

This message is coming from the function _binder when a call to this 
function is made as ...

_binder(0x23,0x40062cd8,0x400bf2fo,0x40052fd0)

I do have access to DDE-MIPS SVR4.2 Sources here and that is how I could 
locate where this message is coming from.

I am attaching the file binder.c which is part of the libc and  rtld for 
mipsr4000. The base for the mips-dde-sysv4.2MP port seems to have mainly 
come from i386 as base.

- ---- Some clip from that (although I am attaching that file at end ) -----

unsigned long _binder( unsigned long sym_index, unsigned long pc)
{
        struct rt_private_map *nlm, *first_lm, *lm;
        char *symname;


- - - - - - 
- - - - - - 
Some  line go here .....

        /* Note that since the MIPS ABI doesn't provide a means for passing
         * lm from the stub routines, so we must get this information
         * someplace else.  Here we just start with the head of the list
         * which is stored in the global variable _ld_loaded.  This may
         * not be correct for objects which have DT_SYMBOLIC set.
         * FIXME!
         */
        lm = _rt_address_to_lm(_ld_loaded,pc);

        if (!lm) {
                _rtfprintf(2, "%s: %s: unidentifiable procedure reference 
(addre
ss = 0x%x)\n",(char*) _rt_name,_proc_name,pc);
                (void)_rtkill(_rtgetpid(), SIGKILL);
        }

- ------------------ End of the clip .. later stuff not here 
- -------------------


So here is the message that I am getting .

But how and why is it happening , I could not think.

Any pointers on this....

Could there be any problems with the start up file like crti, crt1 and crtn used. This is how the linking is done ...

--------------------------------------------------------------------------
 /usr/local/mips-dde-sysv4.2MP/bin/ld /usr/lib/ld.so.1 /usr/local/mips-dde-sysv4.2MP/lib/crt1.o /usr/local/mips-dde-sysv4.2MP/lib/crti.o /usr/local/mips-dde-sysv4.2MP/lib/values-Xa.o -L/usr/local/lib/gcc-lib/mips-dde-sysv4.2MP/egcs-2.91.57 -L/usr/local/mips-dde-sysv4.2MP/lib -L/usr/local/lib /var/tmp/ccrLBNAM.o -lgcc -L/usr/lib -lc -lgcc /usr/local/mips-dde-sysv4.2MP/lib/crtn.o
GNU ld version 2.9.4 (with BFD 990118)
  Supported emulations:
   elf32bsmip
--------------------------------------------------------------------------

Could using the crtbegin and crtend help. Why don't the MIPS targets use them..


Thanks for any help and information in advance.

With best regards

Koundinya

Here is the file binder.c (which is a part of the native libc source )that I am attaching...







Thanks for any help in advance.

Koundinya

Re: GNU Linker and mips...

[Ian Lance Taylor]

   Date: Thu, 11 Feb 1999 20:00:02 +0530
   From: "Koundinya.K" <kk@ddeorg.soft.net>

	   /* Note that since the MIPS ABI doesn't provide a means for passing
	    * lm from the stub routines, so we must get this information
	    * someplace else.  Here we just start with the head of the list
	    * which is stored in the global variable _ld_loaded.  This may
	    * not be correct for objects which have DT_SYMBOLIC set.
	    * FIXME!
	    */
	   lm = _rt_address_to_lm(_ld_loaded,pc);

Can you find out what _ld_loaded is initialized to?

   But how and why is it happening , I could not think.

It looks like your dynamic linker expects some sort of structure which
the GNU linker is not setting up.

   Could there be any problems with the start up file like crti, crt1 and crtn used.

I doubt it.

   Could using the crtbegin and crtend help. Why don't the MIPS targets use them..

I doubt this would make any difference either.  The Irix targets don't
use crtbegin and crtend because the Irix linker has another mechanism
for ensuring that the global constructors will run.  Your target may
need crtbegin and crtend, but using them won't fix the problem you are
encountering.

Ian

Re: Problem with GNU Linker on mips...

[Koundinya.K]

Hello,
	First of all a quick thanks to Ian for the response to my queries.

O.K
->    Date: Thu, 11 Feb 1999 20:00:02 +0530
->    From: "Koundinya.K" <kk@ddeorg.soft.net>
-> 
-> 	   /* Note that since the MIPS ABI doesn't provide a means for passing
-> 	    * lm from the stub routines, so we must get this information
-> 	    * someplace else.  Here we just start with the head of the list
-> 	    * which is stored in the global variable _ld_loaded.  This may
-> 	    * not be correct for objects which have DT_SYMBOLIC set.
-> 	    * FIXME!
-> 	    */
-> 	   lm = _rt_address_to_lm(_ld_loaded,pc);
-> 
-> Can you find out what _ld_loaded is initialized to?
-> 

Yes and no , I am not able to watch the elements of the structure. 
_ld_loaded contains the value 1074495092 and the address of _ld_loaded is 
419304.


-> It looks like your dynamic linker expects some sort of structure which
-> the GNU linker is not setting up.
-> 


->    Could there be any problems with the start up file like crti, crt1 and crtn used.
-> 
-> I doubt it.
-> 
->    Could using the crtbegin and crtend help. Why don't the MIPS targets use them..
-> 
-> I doubt this would make any difference either.  The Irix targets don't
-> use crtbegin and crtend because the Irix linker has another mechanism
-> for ensuring that the global constructors will run.  Your target may
-> need crtbegin and crtend, but using them won't fix the problem you are
-> encountering.
-> 
-> 

Yes as you say, I don't think my target requires the crtbegin and end.

THen I then realized this when I saw what my native EPC compiler used. It is 
very similar to IRIX*

------Clip of what my native compiler uses ------------------------------
$cc -Wl,-note -V t.c -o tt

EPC ANSI C 3.0.12
Copyright (c) 1991,1992,1993,1994,1995 EPCL. All Rights Reserved
Copyright (c) 1990,1991 UNIX System Laboratories, Inc.
Copyright (c) 1988 AT&T
ecc: C Development Set  (ECCS) (3.0.12) Jun  6 1995
acomp: C Development Set  (ECCS) (3.0.12) Jun  7 1995
as: (EPC MIPS-2 Compilation Tools) 3.6.3 Apr 11 1995
ld: EPC MIPS-2 Compilation Tools (3.6.6) Apr 11 1995
ld: /opt/epc/ecc/epctools/crt1.o: notice: reading: ELF flags=0x000003
ld: /opt/epc/ecc/epctools/crti.o: notice: reading: ELF flags=0x000003
ld: /opt/epc/ecc/epctools/values-Xt.o: notice: reading: ELF flags=0x000002
ld: t.o: notice: reading: ELF flags=0x000005
ld: /opt/epc/ecc/epctools/crtn.o: notice: reading: ELF flags=0x000002
ld: /usr/ccs/lib/libc.so(libc.so.1): notice: reading: ELF flags=0x10000003
-----------------------------------------------------------------------------


I am still in the process of debugging. I found out something else. I tried 
to debug one test program. (both using gas)

1) Using gcc and native linker

2) Using gcc and the gnu linker.

I) In the first case as usual I don't have any problem.

From the _exithandle() , _fini is called.

__________________ Clip of the debugging __________________________________
0x40062cc8 in _exithandle ()
0x40062ccc in _exithandle ()
0x40062cd0 in _exithandle ()
0x400744 in _fini ()
0x400748 in _fini ()
0x400750 in _fini ()

____________________ Later stuff not shown _________________________

II)

How ever in the second case the _fini () is *not* being called . Instead 
_etext is being called from where on after return to _exithandle -> _cleanup 
() -> _rtbinder ........ message "unidentifiable procedure reference 
(address =0x40062cd8
Killed

___________________ Clip of the debugging ___________________________________

0x40062ccc in _exithandle ()
0x40062cd0 in _exithandle ()
0x4009c0 in _etext ()
0x4009c4 in _etext ()
0x4009cc in _etext ()
0x4009d0 in _etext ()
 ... ... ... ... ... 
... .. .. .. .. .. .. ..
0x4009ec in _etext ()
0x40062cd8 in _exithandle ()
0x40062cdc in _exithandle ()
0x40062ce0 in _exithandle ()
0x40062ce4 in _exithandle ()
0x40062cc4 in _exithandle ()
0x40062cc8 in _exithandle ()
0x40062ccc in _exithandle ()
0x40062cd0 in _exithandle ()
0x400980 in _cleanup ()
0x400984 in _cleanup ()
0x400988 in _cleanup ()
0x40052f60 in _rtbinder ()
0x40052f64 in _rtbinder ()
0x40052f68 in _rtbinder ()

........
........
dynamic linker: unidentifiable procedure reference (address = 0x40062cd8)
killed

_____________________Later stuff not shown __________________________________


So I can see that _fini() is not being called , (which I think should be)...

Any pointers on this will help me for further debugging. Or may be this 
could solve the problem , I suppose.

Thanks in advance for any help received.

With best regards

Koundinya