m2-internship/libunwind-eh_elf
1
0
Fork 0
mirror of https://github.com/tobast/libunwind-eh_elf.git synced 2024-05-19 11:35:17 +02:00
Code Issues Releases Activity

Update.

Browse source 
(Logical change 1.153)
This commit is contained in:
hp.com!davidm 2004-01-20 01:51:17 +00:00
parent 63390c2267
commit a7aaf01e8a
1 changed files with 26 additions and 24 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

50
TODO
View file

@ -1,32 +1,14 @@
- Update the libunwind man page for the new/fixed cache-flushing behavior.
Effectively, that unw_flush_cache() doesn't have to be called by
applications except for extraordinary circumstances (e.g., if application
implements its own runtime loader).
- document split local-only/generic libraries and separate libunwind-ptrace.a
convenience-library
- implement non-local versions of dwarf_readXX()
- document new "tdep" member in unw_proc_info_t structure
- for DWARF 2, use a dummy CIE entry with an augmentation that
provides the dyn-info-list-address
- caching is pretty fundamentally broken, what should happen is this:
o On unw_init_local()/unw_init_remote(), libunwind should validate
that the cached information is still valid and, if not, flush the
cache on its own. Rational: once unw_init_local() has been
called, it is clear that the unwind info for the calling thread
cannot change (otherwise the program would be buggy anyhow) and
hence it is sufficient to validate the cache at this point.
Similarly, once unw_init_remote() has been called, the target
address space must have been stopped, because the unwinding would
otherwise be unreliable anyhow.
o glibc currently lacks a feature for dl_iterate_phdr() to support
safe caching; I proposed on 12/16/2003 that glibc maintain two
atomic counters which get inremented whenever something is added
to/removed from the dl_iterate_phdr-list. Once we have such counters,
we can use them in libunwind to implement an efficient version of a
cache-validation routine.
Once this has been fixed, update the libunwind man page accordingly.
Effectively, what this means is that unw_flush_cache() doesn't have
to be called by applications except for extraordinary circumstances
(e.g., if application implements its own runtime loader).
Testing:
- ensure that saving r4-r7 in a stacked register properly preserves
the NaT bit, even in the face of register-rotation
@ -37,6 +19,26 @@ Testing:
=== taken care of:
+ caching is pretty fundamentally broken, what should happen is this:
o On unw_init_local()/unw_init_remote(), libunwind should validate
that the cached information is still valid and, if not, flush the
cache on its own. Rationale: once unw_init_local() has been
called, it is clear that the unwind info for the calling thread
cannot change (otherwise the program would be buggy anyhow) and
hence it is sufficient to validate the cache at this point.
Similarly, once unw_init_remote() has been called, the target
address space must have been stopped, because the unwinding would
otherwise be unreliable anyhow.
o glibc currently lacks a feature for dl_iterate_phdr() to support
safe caching; I proposed on 12/16/2003 that glibc maintain two
atomic counters which get inremented whenever something is added
to/removed from the dl_iterate_phdr-list. Once we have such counters,
we can use them in libunwind to implement an efficient version of a
cache-validation routine.
Once this has been fixed, update the libunwind man page accordingly.
Effectively, what this means is that unw_flush_cache() doesn't have
to be called by applications except for extraordinary circumstances
(e.g., if application implements its own runtime loader).
+ man-page for unw_is_fpreg()
+ man-page for _U_dyn_cancel()
+ man-page for _U_dyn_register()