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
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
Ebl * now, but the user doesn't have, and shouldn't have, a way to
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
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.