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]

Difficulties while adding local init_regs support to libebl

I now have a few patches [1] adding support for collecting initial
register values from the current thread. While I believe the initial
register collection logic works (it works for GHC), I have encountered
an unfortunate issue while folding this code into libebl. Namely, it
seems that libebl backends are dynamically loaded.

To see why this is problematic, consider this example,

  // libdwfl now provides this,
  int dwfl_linux_local_attach (Dwfl *dwfl) {
    // local_thread_callbacks uses ebl_set_initial_registers_local
    // which is now provided by libebl
    dwfl_attach_state(dwfl, NULL, pid, &local_thread_callbacks, NULL);

  // Here is the test-case,
  void test() {
    Dwfl *dwfl = dwfl_begin (&proc_callbacks);

    // Figure out what modules are loaded
    dwfl_linux_proc_report(dwfl, getpid());
    dwfl_report_end (dwfl, NULL, NULL);

    // but the ebl backend,, only gets loaded here

    // therefore when we begin to unwind we have no debug information
    // for libebl, which is where PC sits when we collect the initial
    // register values. Unwinding consequently fails
    dwfl_getthread_frames (dwfl, getpid(), frame_cb, dwfl) != 0;

The issue here is that debug information is not reported to libdwfl as
it is not loaded at the time we report the loaded modules.

At this point I'm a bit unsure of how to proceed. I can think of a few

  * teach dwfl_linux_local_attach to report libebl when it gets
    loaded. This would be rather ugly as we would either need to
    re-read the /proc map data or somehow extract the necessary
    information from the dynamic linker

  * Expose an entirely different interface from dwfl_getthread_frames
    for local unwinding such that PC doesn't sit within libebl when
    initial register values are collected.

    This would likely involve turning it into an inline function defined
    in a header which could grab the initial register values,

        // For instance, in the case of x86_64
        #if defined(__x86_64__) && defined(__linux__)
        static inline void
        dwfl_get_frames_here(Dwfl *dwfl,
                             void (*cb)(Frame *, void*),
                             void *cbdata)
            Thread thread = ...; // need to figure out what to put here
            Dwarf_Word regs[17];
            __asm__ (( "// Grab registers " ));
            dwfl_thread_state_registers(thread, 0, 17, regs);

    Unfortunately this is quite a departure from the current interface
    and seems to break the nice separation between libebl and the

    I also don't really know how to correctly handle the
    rather subtle distinction between 32-/64-bit programs running on
    32-/64-bit kernels.

  * Something I haven't yet thought of...

Any ideas?


- Ben


Attachment: signature.asc
Description: PGP signature

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