This is the mail archive of the mailing list for the elfutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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

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


Going to post some updated and more split patch, unless you reply to the Ebl
issues above earlier.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]