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
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
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?
> 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