This is the mail archive of the mailing list for the frysk project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: libunwind

Roland McGrath wrote:
It needs two kinds of things.  One is access to the active thread/process
state, which is to say registers and memory.  That goes to the frysk core
that is what's calling into libunwind.

The other is access to the unwind info from the ELF files.  This is data in
whole ELF sections (.debug_frame, .eh_frame) that nothing but the unwinder
needs to think about.  The raw section contents are easily gotten from
libdwfl+libelf calls starting from the Dwfl object for an address space.

The libunwind callbacks are especially poorly structured so that you need
to wade into a bunch of weirdness to have your callbacks use some libunwind
code that does part of the DWARF parsing, instead of simply supplying
libunwind with the raw sections it needs.
I like the idea of grabbing whole memory segmends from lib{dwfl,elf} and passing that into
libunwind (or more specifically: the libunwind wrapper, most likely via a bytebuffer) rather than trying to mimic the C callbacks.
There will still be some callbacks required for registers et al. but I think this would be a much
cleaner approach.

Does this sounds feasible?

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]