GNU linker on MIPS and the _etext section ....

GNU linker on MIPS and the _etext section ....

[Koundinya.K]

Dear all and Ian,
	I have some doubt regarding the _etext section. I am still in the process 
of debugging the GNU linker. After some hours of debugging last night I 
found that my runtime linker is getting killed because a call to the _etext 
is resulting in a procedure linkage table entry for my run time linker. 
After this all the binder code of the run time linker is called and then the 
linker gets killed. I don't know how far I am correct. Here is my 
observation of a test program that I first compiled using gcc and native ld 
, then compiled again with gcc and gnu ld.

1) gcc and the native ld.	(No problem here )

_____________ Earlier Stuff not shown ____________________________________
__________________________________________________________________________

0x40062ed8 in _exithandle ()
0x40062edc in _exithandle ()
0x40062ee0 in _exithandle ()
0x400744 in _fini ()
0x400748 in _fini ()
0x400750 in _fini ()
0x400754 in _fini ()
0x400758 in _fini ()
0x40075c in _fini ()
0x400760 in _fini ()
0x400764 in _fini ()
0x400768 in _fini ()
0x40076c in _fini ()
0x400770 in _fini ()
0x40062ee8 in _exithandle ()
0x40062eec in _exithandle ()
0x40062ef0 in _exithandle ()
0x40062ef4 in _exithandle ()
_________________________ Later stuff not shown _____________________________
_

2) gcc and GNU ld 

_________________________________________________________________________
_________________ Earlier Stuff not shown _________________________________

0x40062ed4 in _exithandle ()
0x40062ed8 in _exithandle ()
0x40062edc in _exithandle ()
0x40062ee0 in _exithandle ()
0x4009c0 in _etext ()
0x4009c4 in _etext ()
0x4009cc in _etext ()
0x4009d0 in _etext ()
0x4009d4 in _etext ()
0x4009d8 in _etext ()
0x4009dc in _etext ()
0x4009e0 in _etext ()
0x4009e4 in _etext ()
0x4009e8 in _etext ()
0x4009ec in _etext ()
0x40062ee8 in _exithandle ()
0x40062eec in _exithandle ()
0x40062ef0 in _exithandle ()
0x40062ef4 in _exithandle ()
0x40062ec4 in _exithandle ()
0x40062ec8 in _exithandle ()
0x40062ecc in _exithandle ()
0x40062ed0 in _exithandle ()
0x40062ed4 in _exithandle ()
0x40062ed8 in _exithandle ()
0x40062edc in _exithandle ()
0x40062ee0 in _exithandle ()
0x400980 in _cleanup ()
0x400984 in _cleanup ()
0x400988 in _cleanup ()
0x40051310 in _rtbinder ()
0x40051314 in _rtbinder ()

after many more steppings I get ...

Hello
dynamic linker: ./tt1: unidentifiable procedure reference (address = 
0x40062ee8)
Killed

_____________________________________________________________________________
__


I am using gdb for debugging. 

For gcc + gnu ld combination I am able to step into the _etext function.

For the gcc + native ld combination I am not able to get into _etext ().

I get a message from gdb like this.

_____________________________________________________________________________
__
(gdb) break _etext
warning: Hit heuristic-fence-post without finding
warning: enclosing function for address 0x400778
This warning occurs if you are debugging a function without any symbols
(for example, in a stripped executable).  In that case, you may wish to
increase the size of the search with the `set heuristic-fence-post' command.

Otherwise, you told GDB there was a function where there isn't one, or
(more likely) you have encountered a bug in GDB.
Breakpoint 2 at 0x400778

_____________________________________________________________________________


I would be glad I can get any pointers on these issues and the problem that 
I am facing.

With best regards

Koundinya



	

Re: GNU linker on MIPS and the _etext section ....

[Ian Lance Taylor]

   Date: Sat, 20 Feb 1999 14:17:50 +0530
   From: "Koundinya.K" <kk@ddeorg.soft.net>

	   I have some doubt regarding the _etext section.

_etext is not a section.  It is a symbol.  It normally marks the end
of the .text section.

   I am still in the process 
   of debugging the GNU linker. After some hours of debugging last night I 
   found that my runtime linker is getting killed because a call to the _etext 
   is resulting in a procedure linkage table entry for my run time linker. 

Nothing is calling _etext.  gdb is seeing a call to some address.  It
can't find a symbol associated with that address.  The address happens
to be after _etext, so it decides to call the address _etext plus
something.  Don't pay any attention to _etext--that's just a red
herring resulting from how gdb decides to display addresses.

Your program is actually calling into code for which gdb can not find
any debugging information.  This code is probably in the dynamic
linker, or in a shared library.

Ian