This is the mail archive of the
mailing list for the elfutils project.
Re: [patch v5] unwinder: The unwinder (x86* only)
- From: Mark Wielaard <mjw at redhat dot com>
- To: elfutils-devel at lists dot fedorahosted dot org
- Date: Sat, 12 Oct 2013 22:52:23 +0200
- Subject: Re: [patch v5] unwinder: The unwinder (x86* only)
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 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.