This is the mail archive of the
gdb-prs@sources.redhat.com
mailing list for the GDB project.
Re: gdb/1475: chdir(), dlopen() using relative path fails to trackmodule
- From: Daniel Reed <n at ml dot org>
- To: nobody at sources dot redhat dot com
- Cc: gdb-prs at sources dot redhat dot com,
- Date: 5 Dec 2003 21:08:00 -0000
- Subject: Re: gdb/1475: chdir(), dlopen() using relative path fails to trackmodule
- Reply-to: Daniel Reed <n at ml dot org>
The following reply was made to PR gdb/1475; it has been noted by GNATS.
From: Daniel Reed <n@ml.org>
To: Kevin Buettner <kevinb@redhat.com>
Cc: gdb-gnats@sources.redhat.com
Subject: Re: gdb/1475: chdir(), dlopen() using relative path fails to track
module
Date: Fri, 5 Dec 2003 16:00:53 -0500 (EST)
On 2003-12-05T13:13-0700, Kevin Buettner wrote:
) On Dec 5, 7:48pm, n@ml.org wrote:
) > Create a gcc -shared /tmp/test.so and a simple program that does:
) > chdir("/tmp"); dlopen("./test.so", RTLD_LAZY);
) > Run the simple program in gdb. Changing the dlopen() call to "/tmp/test.so" works as expected.
...
) I recommend using ``set solib-search'' to allow gdb to find the shared
) object.
That would surely work if I knew what my working directory would be
beforehand (i.e. naim always chdir()s to $HOME at start). For the general
case, however, would it be possible to catch chdir() and track CWD that way?
As a further bit of information, if I run the simple program out of /tmp to
begin with, gdb works as expected with dlopen("./test.so"). It's only when
the CWD actually changes that GDB is unable to find the library using a
relative path.
--
Daniel Reed <n@ml.org> http://naim-users.org/nmlorg/ http://naim.n.ml.org/
"Real computer scientists like having a computer on their desk, else
how could they read their mail?"