| Summary: | support $globals in shared libraries | ||
|---|---|---|---|
| Product: | systemtap | Reporter: | Frank Ch. Eigler <fche> |
| Component: | translator | Assignee: | Frank Ch. Eigler <fche> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | srikar |
| Priority: | P2 | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Host: | Target: | ||
| Build: | Last reconfirmed: | ||
| Bug Depends on: | 6866 | ||
| Bug Blocks: | 10013 | ||
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. Need has become urgent. 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. 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. (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. |
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.