Relative and absolute paths in link_map

Relative and absolute paths in link_map

[Levchenko, Vasily V]

[-- Attachment #1: Type: text/plain, Size: 172 bytes --]

Hi,
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.
--
:vvl

[-- Attachment #2: tls.patch --]
[-- Type: application/octet-stream, Size: 580 bytes --]

Index: gdb/solib-svr4.c
===================================================================
RCS file: /cvs/src/src/gdb/solib-svr4.c,v
retrieving revision 1.47
diff -r1.47 solib-svr4.c
733c733,738
< 	  if ((buffer && strcmp (buffer, objfile->name) == 0)
---
>          char *libname_buffer, *libname;
>          libname_buffer = strrchr(buffer, '/');
>          libname = strrchr(objfile->name, '/');
> 	  if ((buffer 
>                 && (( libname_buffer && strcmp(libname_buffer, libname) == 0 )
>                 || (!libname_buffer &&  strcmp (buffer,objfile->name ) == 0)))

Re: Relative and absolute paths in link_map

[Kevin Buettner]

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?

Your patch is small enough that it can likely go in without an FSF
copyright assignment.  You should know, however, that most patches
require some sort of copyright assignment.  If you think you might
make further contributions to GDB in the future, you should make the
proper legal arrangements.  If this is something that you're
interested in, let me know, and I will ask to have the necessary
documents sent to you.

Again, I thank you for your patch, and hope that you can provide me
with the some sort of test case or at least a description of the
scenario in which your patch is needed.

Kevin

Re: Relative and absolute paths in link_map

[Daniel Jacobowitz]

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.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Relative and absolute paths in link_map

[Kevin Buettner]

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

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