Bug 10010 - support $globals in shared libraries
Summary: support $globals in shared libraries
Status: RESOLVED FIXED
Alias: None
Product: systemtap
Classification: Unclassified
Component: translator (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Frank Ch. Eigler
URL:
Keywords:
Depends on: 6866
Blocks: 10013
  Show dependency treegraph
 
Reported: 2009-03-27 15:49 UTC by Frank Ch. Eigler
Modified: 2009-11-24 20:36 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Frank Ch. Eigler 2009-03-27 15:49:54 UTC
tapsets.cxx (dwflpp::emit_address) has this little defensive ditty:

        else
          {
            throw semantic_error ("cannot relocate user-space dso (?) address");
#if 0
            // This would happen for a Dwfl_Module that's a user-level DSO.    
                                            
            obstack_printf (pool, " /* %s+%#" PRIx64 " */",
                            modname, address);
#endif
          }

It should be easy to fill that in to make it emit the right code to relocate
shlib-based addresses.  That though requires _stp_relocate_FOO to be aware
of per-process address spaces, which is bug #6866.
Comment 1 Mark Wielaard 2009-05-25 10:35:51 UTC
I am not currently working on this.

It would be good to have a sample testcase to show what is needed for this to be
fully supported.
Comment 2 Frank Ch. Eigler 2009-09-09 19:06:58 UTC
Need has become urgent.
Comment 3 Mark Wielaard 2009-11-17 08:14:46 UTC
commit a295050e60affe0bb55fc2d46637314c0822f35d
Author: Mark Wielaard <mjw@redhat.com>
Date:   Mon Nov 16 21:34:00 2009 +0100

    PR10010 Support $globals in shared libraries.
    
    * dwflpp.cxx (dwflpp::emit_address): Enable task finder and emit a
      _stp_module_relocate for the ".dynamic" section when seeing a
      user-space dso address.
    * runtime/sym.c (_stp_mod_sec_lookup): Remove .dynamic section addr cheat.
      (_stp_tf_mmap_cb): Add cheat here.
Comment 4 Frank Ch. Eigler 2009-11-20 19:49:57 UTC
The new code appears to use _stp_modules[...]->sections[0].addr as "the"
(systemwide) shared library load address.  However this is wrong: there
can be distinct load addresses for each process that maps in the widget
So the address would need to be looked up in the appropriate
__stp_tf_vma_entry record.

If the present hack is deemed good enough (in light of prelinking or whatnot),
and we don't want to handle the full generality yet, at least we need
diagnostics to detect the case where a new load address for the same shared
library is found.
Comment 5 Mark Wielaard 2009-11-24 20:36:50 UTC
(In reply to comment #4)
> The new code appears to use _stp_modules[...]->sections[0].addr as "the"
> (systemwide) shared library load address.  However this is wrong: there
> can be distinct load addresses for each process that maps in the widget
> So the address would need to be looked up in the appropriate
> __stp_tf_vma_entry record.
> 
> If the present hack is deemed good enough (in light of prelinking or whatnot),
> and we don't want to handle the full generality yet, at least we need
> diagnostics to detect the case where a new load address for the same shared
> library is found.

Yes, it is "good enough" for now (as in, I haven't seen an issue in practise
yet, although I agree it is an issue). The code was already there, it just moved
around a bit in the last commit. But it is indeed something that needs to be
flagged if it happens and resolved. I added an check and error for this
condition and opened a new bug report PR11015.

commit b2f9c9051897d50ad59b06f9e305083eab84fd4b
Author: Mark Wielaard <mjw@redhat.com>
Date:   Tue Nov 24 21:29:57 2009 +0100

    Add assert for detecting shared library reloading, PR11015.
    
    * runtime/sym.c (_stp_tf_mmap_cb): Only look for first load of whole module
      that is executable. Add check for detecting reloading of module.