12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879808182838485868788899091929394959697 |
- - 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
- - 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
- === taken care of:
- Testing:
- + ensure that saving r4-r7 in a stacked register properly preserves
- the NaT bit, even in the face of register-rotation
- + ensure that IA64_INSN_MOVE_STACKED works correctly in the face of
- register rotation
- + on Linux, test access to f32-f127 in a signal handler (e.g., verify
- that fph partition gets initialized properly)
- + According to Nicholas S. Wourms <nwourms@netscape.net>, adding this to the
- Makefile.am:
- AUTOMAKE_OPTIONS = 1.6 subdir-objects
- ensures that object-files are build in separate subdirectories and that
- in turn makes it possible for source files in different directories to
- have the same filename, thus avoiding the need for those ugly -x86, -ia64,
- etc., postfixes.
- + Switch ia64 (and rest over) to using Debug() instead of debug()
- + implement non-local versions of dwarf_readXX()
- + consolidate mostly architecture-independent code such as
- unw_get_accessors() into shared files
- + 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()
- + global data is not protected by a lock; causes problems if two threads
- call ia64_init() at almost the same time
- + cache the value of *cfm_loc; each rotate_FOO() call needs it!
- + implement the remote-lookup of the dynamic registration list
- + when doing sigreturn, must restore fp regs (and perhaps other regs) the same
- way as the (user-level) gate.S sigreturn path does!
- + unw_resume() must at least restore gp (r1)! consider restoring all
- scratch regs (but what's the performance impact on exception handling?);
- alternative: restore scratch regs that may be used during procedure
- call/return (e.g., r8-r11, f8-f11)
- + implement unw_resume() for the case where the current register frame is split
- across multiple backing stores
- + document restricions on using unw_resume():
- + implement remote cases of unw_resume()
- + test both with UNW_LOCAL_ONLY and without where this makes sense
- + allow region-length (insn_count) in unw_dyn_region_info_t to be negative
- to indicate counting from the end of the procedure (to make it possible
- for differently-sized procedures to share the same region list if they
- share the same prologue/epilogue).
- + it appears that it is currently not possible to read register UNW_IA64_TP;
- fix that => no, attempts to access r13 will result in access_reg() callbacks,
- as desired; for local-case, access to r13 will fail though (since
- getcontext() doesn't, and shouldn't, capture r13)
- + document the special nature of UNW_IA64_GP: read-only, but adjusted
- automatically if the IP is changed
- + use pthread-mutexes where necessary, atomic ops where possible
- + man-page for unw_init_local()
- + man-page for unw_init_remote()
- + man-page for unw_create_addr_space()
- + man-page for unw_destroy_addr_space()
- + man-page for unw_get_proc_info()
- + man-page for unw_get_proc_name()
- + man-page for unw_get_accessors()
- + man-page for unw_regname()
- + man-page for unw_flush_cache()
- + man-page for unw_set_caching_policy()
- + man-page for unw_getcontext()
- + man-page for unw_is_signal_frame()
- + man-page for unw_step()
- + man-page for unw_get_reg()
- + man-page for unw_set_reg()
- + man-page for unw_get_fpreg()
- + man-page for unw_set_fpreg()
- + test with Intel compiler
|