From: David Mosberger <davidm@hpl.hp.com>
To: linux-ia64@vger.kernel.org
Subject: RE: [Linux-ia64] problem with unwind info for .init/.fini section
Date: Thu, 28 Feb 2002 21:47:30 +0000 [thread overview]
Message-ID: <marc-linux-ia64-105590701905204@msgid-missing> (raw)
In-Reply-To: <marc-linux-ia64-105590701905179@msgid-missing>
>>>>> 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
prev parent reply other threads:[~2002-02-28 21:47 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-02-22 19:54 [Linux-ia64] problem with unwind info for .init/.fini sections David Mosberger
2002-02-27 19:19 ` 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 ` David Mosberger [this message]
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-105590701905204@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