public inbox for linux-ia64@vger.kernel.org
 help / color / mirror / Atom feed
From: David Mosberger <davidm@hpl.hp.com>
To: linux-ia64@vger.kernel.org
Subject: [Linux-ia64] problem with unwind info for .init/.fini sections
Date: Fri, 22 Feb 2002 19:54:27 +0000	[thread overview]
Message-ID: <marc-linux-ia64-105590701905179@msgid-missing> (raw)

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


             reply	other threads:[~2002-02-22 19:54 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-02-22 19:54 David Mosberger [this message]
2002-02-27 19:19 ` [Linux-ia64] problem with unwind info for .init/.fini sections Cary Coutant
2002-02-28 12:02 ` [Linux-ia64] problem with unwind info for .init/.fini section Zagorodnev, Grigory
2002-02-28 21:33 ` [Linux-ia64] problem with unwind info for .init/.fini sections David Mosberger
2002-02-28 21:47 ` [Linux-ia64] problem with unwind info for .init/.fini section David Mosberger

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=marc-linux-ia64-105590701905179@msgid-missing \
    --to=davidm@hpl.hp.com \
    --cc=linux-ia64@vger.kernel.org \
    /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