public inbox for bfd@sourceware.org
 help / color / mirror / Atom feed
From: "Koundinya.K" <kk@ddeorg.soft.net>
To: Ian Lance Taylor <ian@cygnus.com>
Cc: bfd@cygnus.com, gas2@cygnus.com
Subject: Re: Problem with GNU Linker on mips...
Date: Thu, 18 Feb 1999 06:39:00 -0000	[thread overview]
Message-ID: <199902181439.UAA13324@bombay.ddeorg.soft.net> (raw)
In-Reply-To: <199902111620.LAA00234@subrogation.cygnus.com>

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


      reply	other threads:[~1999-02-18  6:39 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-02-11  6:32 GNU Linker and mips Koundinya.K
1999-02-11  8:20 ` Ian Lance Taylor
1999-02-18  6:39   ` Koundinya.K [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=199902181439.UAA13324@bombay.ddeorg.soft.net \
    --to=kk@ddeorg.soft.net \
    --cc=bfd@cygnus.com \
    --cc=gas2@cygnus.com \
    --cc=ian@cygnus.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).