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: Difficulties while adding local init_regs support to libebl


Hi Ben,

On Fri, Sep 04, 2015 at 01:29:18PM +0200, Ben Gamari wrote:
> >> At this point I'm a bit unsure of how to proceed. I can think of a few
> >> options,
> >> 
> >>   * 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
> >
> > It might be interesting to have a Dwfl *dwfl_linux_local_report () that
> > creates a Dwfl using the dynamic linker structures. It could come with a
> > _refresh function or keep things automagically up to date (although that
> > might be tricky with threading). But that seems a but more work than
> > what you signed up for right now.
> >
> That might be the best option although I'm not entirely sure what
> (reasonably portable) interfaces exist for this task.

There is dl_iterate_phdr which is a GNU extensions, but some other
systems have something similar.

> >>   * Something I haven't yet thought of...
> >
> > Maybe you could just do:
> >
> >   dwfl_report_begin (dwfl);
> >   dwfl_linux_proc_report(dwfl, getpid());
> >   dwfl_report_end (dwfl, NULL, NULL);
> >
> > after dwfl_linux_local_attach (), but before dwfl_getthread_frames ().
> >
> > That is supported to simply refreshes the Dwfl_Modules into the Dwfl.
> > The only downside is that you reparse the /proc/pid/maps again, so it
> > isn't as efficient as it could be.
> >
> Yeah, the reparsing is unfortunate but it might be acceptable.
> 
> Unfortunately it seems that libebl_x86_64.so doesn't even appear in
> /proc/$PID/maps, so dwfl_linux_proc_report doesn't find it. I have no
> idea why considering that gdb knows about it. Perhaps the reason is that
> it is loaded with dlopen?

Yes, it will only show up after it is dlopened. And not anymore after
it is dlclosed. Which is why you want to load the backend (and not
unload it again) before listing the current modules.

> This makes me think that your suggestion of building up the module list
> From the dynamic linker's structures might be necessary.

Although it wouldn't bad to have such an interface, I don't think it is
necessary. See below.

> > O, I should have thought of this at the start. Maybe you could just
> > start with an empty Dwfl. Do you need to call dwfl_linux_proc_report ()
> > before dwfl_linux_local_attach () at all? dwfl_linux_local_attach ()
> > should be able to figure out the ebl backend it needs on its own. Then
> > you could just report the modules as above after you called
> > dwfl_linux_local_attach ().
> >
> That's a good question. The only reason I report first is that I thought
> this was what the library expected. If this isn't the case then I
> suppose this is all a moot point.
> 
> Unfortunately, when I do try to move the dwfl_linux_local_attach call
> before dwfl_linux_proc_report the attach call fails in
> dwfl_attach_state, which tries to traverse the loaded modules, I believe
> to identify the architecture. The error message it returns is 
> 
>     linux_local_attach failed: Couldn't find architecture of any ELF

That is because you did as we do, not as we teach :)
dwfl_linux_local_attach is modelled after dwfl_linux_proc_attach, which
calls dwfl_attach_state with as second argument NULL. But note what the
documentation of dwfl_attach_state says about that second Elf * argument:

  Architecture of DWFL modules is specified by ELF, ELF must remain
  valid during DWFL lifetime.  Use NULL ELF to detect architecture from
  DWFL, the function will then detect it from arbitrary Dwfl_Module of
  DWFL.

Passing NULL is kind of lazy. An argument could be made that having state
attached to a Dwfl is useful on itself, even without any Dwfl_Modules
registered. For example one might just be interested in the threads and
the current pc address for a quick sample/profile without even wanting
to extract symbols or a backtrace. And like in your case you might want
to attach state to a Dwfl and then later refresh the Dwfl_Modules to
accurately model the current state of loaded libraries.

Attached is a quick patch to implement that for dwfl_linux_proc_attach.
I think you could use the same for dwfl_linux_local_attach to make the
above possible.

Cheers,

Mark

Attachment: attach.patch
Description: Text document


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