More about .init/.fini
----------------------
Guess you already know, but anyway...

There are two special funtions defined by ELF ABI - _init and _fini. First
one is calling at loadable module (executable or shared library) load time,
sencond one - at unload time. Let's call it "ELF feature".

GNU C run-time library uses this feature to provide initialization mechanism
for other libraries and user code. GNU C startup code defines prologue and
epilogue for functions _init and _finit in sections .init and .fini
correspondingly. Any other object file or library could provide body for
desired function in specified section.

Such approach eliminates exclusive use of ELF feature within the
application. 
Given technique is actually using by GNU C and GNU C++ run-time libraries.

The problem
-----------
Unfortunatelly, GNU C startup code does not provide unwind information for
_init and _fini routines. That falls us to stack unwinding problem.

Options
-------
There are two addition directions to go around the problem I see:
	3) Modify glibc to avoid such hacking
	4) Modify debuger(unwinder) algorithm

For and against
---------------
First of all, is the additional note to proposal #1 (to modify linker).
1) Don't think linker is able to generate more then just frame description.
Only compiler can produce ALL necessary unwinding information.

3) More preferable solution. Guess it's possible to provide another
technique of ELF feature using, which will satisfy debuger. Why don't you
contact glibc people for it?

4) I think it's possible to workaround the init/fini problem inside debuger
itself.
Note that .init and .fini sections are dedicated for given functions only. 

It means that the beginning of _init routine coincides with the beginning of
.init section, length of _init routine equals to length of .init section and
any IP from this range belongs to _init routine body. Same situation with
_fini routine and .fini section.

Such knowledge makes possible to determinate _init/_fini frame during
unwinding.
But there is still no chance to go below _init/_fini routine since there is
no unwinding information for it.

Note: remember that each loadable module has own _init/_fini pair in own
.init/.fini sections.

And, finally, is there a way for "alternative" unwinding on ia64 (with
missing unwind info)? 

Grigory.


-----Original Message-----
From: David Mosberger [mailto:davidm@hpl.hp.com]
Sent: Friday, February 22, 2002 10:54 PM
To: binutils@sources.redhat.com
Cc: linux-ia64@linuxia64.org
Subject: [Linux-ia64] problem with unwind info for .init/.fini sections


I mailed the attached article to libc-hacker yesterday, but forgot to
cc the binutils list.  I'd really appreciate hearing other people's
ideas on how to fix this problem.  While we found the problem with
ia64 linux, I suspect other platforms that rely on unwind info are
likely to be affected as well.

Thanks,

	--david

---
Today I noticed that the .init and .fini sections are lacking the info
needed for reliably unwinding on ia64.  This turns out to be a
somewhat nasty problem to solve, because the section is generated at
linktime.  It's easy to fix up the unwind info for the init/fini
prologues, but it's less clear what to do about the body of these
sections.  I can think of two approaches:

 (1) Change the linker so it updates the unwind info once the final
     .init/.fini section has been created.  This shouldn't be all
     that hard: it requires updating the unwind table entry and
     adjusting the unwind descriptors so that the final body region
     is long enough to cover the entire section.

 (2) Require that each code fragment that goes into the .init/.fini
     section is wrapped like this:

		.proc whatever
		.prologue
		.vframe r32
		.save rp, r33
		.save ar.pfs, r34
		.body
		  :
		ACTUAL INIT CODE
		  :
		.endp

(2) might be somewhat easier to do, but is less efficient (the same
unwind info gets duplicated over and over again for no good reason)
and finding all code sequences that go into .init/.fini would be hard
(e.g., it would require gcc, for sure).

(1) doesn't strike me as a great solution as it would require building
more special-section knowledge into the linker, but the solution would
probably be more reliable and more localized than (2).

Anybody else have a better idea or other comments?

	--david

_______________________________________________
Linux-IA64 mailing list
Linux-IA64@linuxia64.org
http://lists.linuxia64.org/lists/listinfo/linux-ia64