Re: [patch v5] unwinder: The unwinder (x86* only)

[Mark Wielaard <mjw at redhat dot com>]

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