Hi,

This patch reworks the libunwind interface so it just uses the given
accessors to read the unwind table we are feeding it. All mucking in elf
images is now done on the frysk side. (The patch also adds a name field
to ElfImage, which is only used for generating a nice debugging string.)

frysk-imports/libunwind/ChangeLog
2007-12-11  Mark Wielaard  <mwielaard@redhat.com>

        * include/libunwind-common.h.in (unw_get_unwind_table): Add
        unw_accessor_t, remove elf image arguments.
        * src/mi/Gget_unwind_table.c (unw_get_unwind_table): Likewise.
        Rewrite to use unw_accessor_t for reading all data.

frysk-sys/lib/unwind/ChangeLog
2007-12-11  Mark Wielaard  <mwielaard@redhat.com>

        * ElfImage.java (name): New field.
        (ElfImage): Set name.
        (toString): Add name.
        * cni/ElfImage.cxx (mapElfImage): Pass in name.
        * cni/UnwindH.hxx (access_mem): Handle memory holes.
        (get_eh_frame_hdr_addr): New static function.
        (local_access_mem): Likewise.
        (createProcInfoFromElfImage): Use get_eh_frame_hdr_addr and
        local_access_mem.
        (createElfImageFromVDSO): Set name to [vdso].

The careful reader will notice that the interface is still a little
eh_frame_hdr specific and that in theory for the eh_frame_hdr one remote
address space accessor would suffice. This is right, since the eh_frame
and eh_frame_hdr are guaranteed to live in the remote address space. But
for debug_frame tables we need two different accessors since the
debug_frame doesn't live in the inferior address space (it also doesn't
have a nice binary search table). Also the last argument of the
interface is still eh_frame_hdr specific because for the table has
addresses relative to its own hdr start address. Both issues mean that
we can actually get rid of the whole copying of the elfimage completely
(when not dealing with debug_frames) when we just have an eh_frame_hdr.
A future cleanup will do that.

Cheers,

Mark