This is the mail archive of the
mailing list for the elfutils project.
Re: [patch v5] unwinder: The unwinder (x86* only)
- From: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- To: elfutils-devel at lists dot fedorahosted dot org
- Date: Fri, 11 Oct 2013 19:58:29 +0200
- Subject: Re: [patch v5] unwinder: The unwinder (x86* only)
On Fri, 11 Oct 2013 13:24:55 +0200, Mark Wielaard wrote:
> I think it also shouldn't depend on the types. That leads to things like
> having to include libebl.h in libdwfl.h.
it can use s/Ebl */struct ebl */ and omit the libebl.h #include, going to do
it while we discuss other options.
> (As a side note, dwfl_attach_state in libdwfl.h is defined to take an
> Ebl * now, but the user doesn't have, and shouldn't have, a way to
> create one.)
So far I did not know user should not have access to Ebl *.
Then why /usr/include/elfutils/libebl.h
is shipped in elfutils-devel-0.156-5.fc19.x86_64 ?
ebl_openbackend() is exposed there and it creates an Ebl * type.
The change you did is not correct. Formerly core file unwinding did depend on
the core file arch. Currently it depends on arch of a first valid ELF dumped
inside the core file. Due to mmaped data files by binutils/compilers it does
not have to match the core file arch.
Before choosing a better solution I would like to know if really / why
applications should not access Ebl *. And if /usr/include/elfutils/libebl.h
is going to be removed.
> Just make a ebl_state_registers_t callback based on a given
> generic void *arg instead of a Dwfl_Thread *. Only the libdwfl code
> should deal with the specific Dwfl types.
OK, thanks, going to import this change to the branch.
Just as an explanation why did I do it as I did it: I wanted to keep it
type-safe. Unfortunately plain C does not feature templates (like C++) so the
declaration could not be type-safe for all types. But I could not imagine why
someone would want to use it with something different than Dwfl_Thread *
so I found using the opaque type there as the least worst of all choices.
> But in theory it would be nice to be able to support "remote" fetching of
> registers (no idea how that would be implemented though, so please ignore).
I really do not see how to use ptrace remotely. In such case you have for
example GDB remote protocol but there is the register layout already
> Just one concern. How stable is sys/user.h and user_regs_struct? Can we
> build on an older system and expect the header and struct to be usable
> on a newer system?
This is kernel ABI, it should not change and I am not aware it would have ever
> When we untangle the libebl and libdwfl parts we should make our
> reviewing lives a little easier and split that 120K patch into separate
> parts. I would suggest something like: ebl part, x86 backend part,
> libdwfl (and minimal libdw) part, src stack part, tests.
Going to post some updated and more split patch, unless you reply to the Ebl
issues above earlier.