On Fri, Oct 11, 2013 at 07:58:29PM +0200, Jan Kratochvil wrote: > On Fri, 11 Oct 2013 13:24:55 +0200, Mark Wielaard wrote: > > (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.
Yeah, I had wanted to say we shouldn't make it a user include header. But now I see that libasm.h does also expose Ebl *. Hmmm. It didn't used to, and the documentation still claims it doesn't. So I guess there is an example now where Ebl * is exposed to the user interface. But also see our README which explicitly says: "the ABI of the backend modules is not guaranteed. Really, not guarantee whatsoever." So the user cannot rely on anything in libebl.h (except maybe ebl_openbackend and ebl_closebackend). Which is why I find it problematic to use Ebl * in any interface because it will mean people might think it is supported. > 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. Ah, sorry, yeah, missed that. My patch did look a little too simple... Instead of an Ebl *, could dwfl_attach_state take an Elf *? > > 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. Great. Thanks, Mark
