[Linux-ia64] problem with unwind info for .init/.fini sections

[Linux-ia64] problem with unwind info for .init/.fini sections

[David Mosberger]

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

Re: [Linux-ia64] problem with unwind info for .init/.fini sections

[Cary Coutant]

>I can think of two approaches:
>...
>Anybody else have a better idea or other comments?

(3) Use the .init_array and .fini_array sections instead.

-cary

RE: [Linux-ia64] problem with unwind info for .init/.fini section

[Zagorodnev, Grigory]

[-- Attachment #1: Type: text/plain, Size: 4505 bytes --]

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

[-- Attachment #2: Type: application/ms-tnef, Size: 4479 bytes --]

Re: [Linux-ia64] problem with unwind info for .init/.fini sections

[David Mosberger]

>>>>> On Wed, 27 Feb 2002 11:19:30 -0800, Cary Coutant <cary@cup.hp.com> said:

  >> I can think of two approaches:
  >> ...
  >> Anybody else have a better idea or other comments?

  Cary> (3) Use the .init_array and .fini_array sections instead.

This would be by far the cleanest solution.

How well is this supported in binutils at the moment?  I see some
references to it, but am not sure whether there are any holes in its
support.

Are there any reasons *not* to switch to .init_array/.fini_array as
the primary init/fini mechanism?  Besides fixing the unwind problem,
it seems to me it's generally just a much cleaner solution and should
allow us to get rid of some rather ugly hacks in glibc.

	--david

RE: [Linux-ia64] problem with unwind info for .init/.fini section

[David Mosberger]

>>>>> On Thu, 28 Feb 2002 15:02:03 +0300, "Zagorodnev, Grigory" <Grigory_Zagorodnev@stl.sarov.ru> said:

  Grigory> 1)
  Grigory> Don't think linker is able to generate more then just frame
  Grigory> description.  Only compiler can produce ALL necessary
  Grigory> unwinding information.

Of course.  If you read my mail carefully, you'll see that the
suggestion is for the linker to *patch* (update) only the length of
the procedure to which the unwind info applies (and have the
corresponding libc assembly stub provide the rest).  This should be
doable with the ia64 unwind descriptors, though it's not exactly
pretty.

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

It's not really preferable because it will affect all applications
that use .init/.fini.  This includes glibc and gcc, but there may be
others.  Ulrich Drepper doesn't like this solution for glibc.

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

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

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

The ia64 calling conventions make unwind info a required part of an
executable (it's not optional).

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

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

No, that's not an option (see above).

In theory, we could treat the .init/.fini sections as dynamically
generated code and register them with an unwinder at startup.  In
practice, this has two problems: we don't have an API (yet) on
Linux/ia64 for registering dynamically generated code and, more
importantly, since .init gets executed so early, it is likely to be
difficult if not impossible to register dynamic unwind info that early
in the game.

	--david