Re: [patch][rfc] Allow GDB to search for the right libthread_db.so.1

[Hui Zhu <teawater at gmail dot com>]

1.  Could you please add a debug interface like "set debug
linux-thread 1" to let linux-thread-db.c output some debug message?
I met a lot of people have trouble with linux-multi-thread debug.  I
think it will help us a lot.  :)

2.  I still peddle my idea: let libthread-db-search-path can support
single file.  And a make a patch follow your patch. Wish you like it.
:)
---
 linux-thread-db.c |   13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)

--- a/linux-thread-db.c
+++ b/linux-thread-db.c
@@ -642,6 +642,7 @@ thread_db_load_search (void)

   while (*search_path)
     {
+      struct stat buf;
       const char *end = strchr (search_path, ':');
       if (end)
 	{
@@ -674,8 +675,16 @@ thread_db_load_search (void)
 	  memcpy (path, search_path, len + 1);
 	  search_path += len;
 	}
-      strcat (path, "/");
-      strcat (path, LIBTHREAD_DB_SO);
+      if (stat (path, &buf))
+        {
+	  warning (_("Stats the file %s failied."), path);
+	  continue;
+	}
+      if (S_ISDIR (buf.st_mode))
+        {
+          strcat (path, "/");
+          strcat (path, LIBTHREAD_DB_SO);
+	}
       if (try_thread_db_load (path))
 	{
 	  rc = 1;


And thanks for you work.  Your patch is very cool.


Thanks,
Hui



On Tue, May 12, 2009 at 02:08, Paul Pluzhnikov <ppluzhnikov@google.com> wrote:
> On Mon, May 11, 2009 at 6:12 AM, Pedro Alves <pedro@codesourcery.com> wrote:
>
>>> handle = dlopen (library, RTLD_NOW);
>>
>> I wonder if making this RTLD_LAZY until you found the correct one
>> wouldn't make sense?
>
> I don't believe so.
>
> AFAICT, the reason for RTLD_NOW is to make sure that this
> libthread_db is really compatible with this GDB (doesn't require
> any symbols GDB doesn't provide); and also to prevent GDB from
> dying half way through with "unable to resolve symbol ...".
>
> Both of these still apply to whatever the "final" libthread_db is
> going to be.
>
> Why would we want to dlopen(... RTLD_LAZY) and try to initialize
> libthread_db if we are going to reject it as unusable in the end?
>
>>> +static int
>>> +thread_db_load_search ()
>>
>> ? ? ? ? ? ? ? ? ? ? ? ? ^ (void)
>
> Fixed, thanks.
>
>> ?(this function could be made to use `openat' at some point, but
>> ? gdb is already assumes PATH_MAX is largest path possible elsewhere
>> ? anyway)
>>
>> I also wonder if `set sysroot' should affect this search path: I think
>> not, but I'm not 100% sure.
>
> I don't believe it makes sense for 'set sysroot' to affect this
> search path.
>
>>> +int libpthread_name_p (const char *name)
>>> +{
>>
>> ? ? ?^ function name at column 0, please.
>
> Fixed, thanks.
>
> Anxiously waiting for Daniel's verdict now ...
>
> --
> Paul Pluzhnikov
>