Re: Relative and absolute paths in link_map

[Kevin Buettner <kevinb at redhat dot com>]

On Thu, 17 Feb 2005 12:43:26 -0500
Daniel Jacobowitz <drow@false.org> wrote:

> On Thu, Feb 17, 2005 at 09:14:15AM -0700, Kevin Buettner wrote:
> > On Thu, 17 Feb 2005 18:20:43 +0300
> > "Levchenko, Vasily V" <vasily.v.levchenko@intel.com> wrote:
> > 
> > > This is a patch corrects comparing of the shared object names which
> > > could be relative and absolute.
> > > Situation:
> > > 	To get tls-variable from shared library.
> > 
> > Hi Vasily,
> > 
> > Thanks for your patch!
> > 
> > In the future, please send some sort of context diff, that is, patches
> > generated either with "diff -u" or "diff -C".  (I also like it when the
> > "-p" switch is used.)
> > 
> > I have read your patch and understand what it is doing, but before
> > putting your change in, I'd first like to understand why it's necessary.
> > Could you offer a bit more explanation about why it is needed?  Do you
> > happen to have a small test case?
> 
> I'd also like to see a testcase.  The patch compares only the basenames
> of libraries (it should use lbasename from libiberty, by the way), but
> it's possible to have two DSO plugins with the same basename and
> different directories loaded.

Actually, I've been thinking about rewriting svr4_fetch_objfile_link_map()
so that it looks more like this (which will be in a forthcoming patch
for remote TLS support on the FR-V):

+CORE_ADDR
+frv_fetch_objfile_link_map (struct objfile *objfile)
+{
+  struct so_list *so;
+
+  /* Cause frv_current_sos() to be run if it hasn't been already.  */
+  if (main_lm_addr == 0)
+    solib_add (0, 0, 0, 1);
+
+  /* frv_current_sos() will set main_lm_addr for the main executable.  */
+  if (objfile == symfile_objfile)
+    return main_lm_addr;
+
+  /* The other link map addresses may be found by examining the list
+     of shared libraries.  */
+  for (so = NULL; ((so = so_list_iterator (so))); )
+    {
+      if (so->objfile == objfile)
+	return so->lm_info->lm_addr;
+    }
+
+  /* Not found!  */
+  return 0;
+}

I haven't included the full patch.  There's a few other bits and pieces
such as the code which sets main_lm_addr in the ``current_sos'' function.

Anyway,...  this method is much more efficient in that it doesn't read
any memory on the target.  It simply uses the list of shared objects
that's already been constructed in GDB.

I suspect that a rewrite like the above will handle whatever case
Vasily's been running into, but I want to understand the exact
scenario first.

Kevin