Hi mark, 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 completely different. > 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 changed. > 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. OK. Going to post some updated and more split patch, unless you reply to the Ebl issues above earlier. Thanks, Jan
