This is the mail archive of the libc-hacker@sources.redhat.com mailing list for the glibc project.

Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

unwind info for .init/.fini sections


[I post this for David --drepper]
David Mosberger <davidm@hpl.hp.com>

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]