Relative and absolute paths in link_map

[Levchenko, Vasily V]

Hi Kevin,

>-----Original Message-----
>From: Kevin Buettner [mailto:kevinb@redhat.com]
>Sent: Thursday, February 17, 2005 11:09 PM
[skipped]
>> >
>> > 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?

Actually we meet with problem that for some reason gdb can't find
linker's link_map for DSO with TLS variable, the problem was that for
some reason comparison for the same shared object was between it
relative path (stored in link_map) and absolute path in objfile->name.
And because at least for linux ld.so it's impossible load two dso with
the same name and different paths, so I use such way. ld.so use first
founded. I'm not very common with gdb internals and libiberty, so it
better of cause to use calculated lib basename. I'll try to make clear
testcase ASAP.

>>
>> 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