This is the mail archive of the elfutils-devel@sourceware.org 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
changed.


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

OK.


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


Thanks,
Jan

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