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

[Doug Evans <dje at google dot com>]

On Thu, Apr 30, 2009 at 12:11 PM, Paul Pluzhnikov
<ppluzhnikov@google.com> wrote:
> On Thu, Apr 30, 2009 at 11:55 AM, Joel Brobecker <brobecker@adacore.com> wrote:
>
>>> 1. If libthread_db_search_path is set, use it *before* trying to load
>>> ? ?libthread_db from the same directory where libpthread was loaded in the
>>> ? ?inferior.
>>
>> From my naive perspective (never really had a need for this feature),
>> it seems better to check the path before checking the path that was
>> used by the inferior. ?Otherwise, if the local host has a library
>> at the same location but that's different from the library used
>> by the inferior, we wouldn't be able to force the debugger to use
>> a different library, would we?
>
> Assume inferior is using remote:/a/b/c/libpthread.so.0.
>
> If host has local:/a/b/c/libthread_db.so.0 which is incompatible with
> remote:/a/b/c/libpthread.so.0, then
> try_thread_db_load("/a/b/c/libthread_db.so.0")
> will fail, and GDB will proceed to try other paths in
> libthread_db_search_path.
>
> But I see your point: if local:/a/b/c/libthread_db.so.0 "agrees"
> to work with the inferior (td_ta_new returns TD_OK), yet is the wrong one
> to use for some reason, there is no way for the user to force GDB to use
> an alternate libthread_db.
>
> I'll invert the order of search, get rid of symbol lookup, and send an
> updated patch shortly.

One could recognize a special path that means the path used by the inferior.
That would also collapse the algorithm from "check A, then check B"
(where A and B are libthread-db-path, inferior-path in some order)
to just "check libthread-db-path".
It's kinda similar to "dir" where "dir" by itself resets the path to $cdir:$cwd,
though in this case one would always set the entire libthread-db-path
whereas the "dir" command prepends to the current path.

Just a thought.