This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
looking for thread_db after exec'ing
- From: Pedro Alves <pedro at codesourcery dot com>
- To: gdb-patches at sourceware dot org
- Date: Wed, 2 Jul 2008 21:29:32 +0100
- Subject: looking for thread_db after exec'ing
I noticed this warning in the testlog of running execl.exp:
warning: Cannot initialize thread debugging library: generic error
This test consists of a program that loads thread_db execing
into another image that does *not* load thread_db.
That warning comes from check_for_thread_db calling
td_ta_new which triggers symbol lookups in the inferior
through the proc interface, which calls into:
197 ps_err_e
198 ps_pglobal_lookup (gdb_ps_prochandle_t ph, const char *obj,
199 const char *name, psaddr_t *sym_addr)
200 {
201 struct minimal_symbol *ms;
202
203 /* FIXME: kettenis/2000-09-03: What should we do with OBJ? */
204 ms = lookup_minimal_symbol (name, NULL, NULL);
205 if (ms == NULL)
206 return PS_NOSYM;
207
208 *sym_addr = core_addr_to_ps_addr (SYMBOL_VALUE_ADDRESS (ms));
209 return PS_OK;
210 }
Now, this is reached after the inferior having having execd, so
"nptl_version" should not be found in the symbol tables, but,
(top-gdb) bt 1
#0 ps_pglobal_lookup (ph=0xa9d7a0, obj=0x7faec28e8261 "libpthread.so.0",
name=0x7faec28e836e "nptl_version",
sym_addr=0x7fffcbd81218) at ../../src/gdb/proc-service.c:205
(top-gdb) p ms
$9 = (struct minimal_symbol *) 0xc415c0
Oops! This process doesn't load libpthread, how was the symbol found?
See attached patch.
Tested on x86_64-unknown-linux-gnu. OK?
Also, the reason I was looking at this test is that, sporadically,
it fails on x86_64 when built with -m32, with:
/home/pedro/gdb/execl_hunt/build32/gdb/testsuite/gdb.threads/execl1: error
while loading shared libraries: libc.so.6: failed to map segment from shared
object: Cannot allocate memory
Any idea what this could be?
--
Pedro Alves
2008-07-02 Pedro Alves <pedro@codesourcery.com>
* infrun.c (follow_exec): Reset shared libraries before adding
the main exec file.
---
gdb/infrun.c | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)
Index: src/gdb/infrun.c
===================================================================
--- src.orig/gdb/infrun.c 2008-07-02 20:55:22.000000000 +0100
+++ src/gdb/infrun.c 2008-07-02 21:10:15.000000000 +0100
@@ -419,13 +419,17 @@ follow_exec (int pid, char *execd_pathna
/* That a.out is now the one to use. */
exec_file_attach (execd_pathname, 0);
- /* And also is where symbols can be found. */
+ /* Reset the shared library package. This ensures that we get a
+ shlib event when the child reaches "_start", at which point the
+ dld will have had a chance to initialize the child. */
+ /* Also, loading a symbol file below may trigger symbol lookups, and
+ we don't want those to be satisfied by the libraries of the
+ previous incarnation of this process. */
+ no_shared_libraries (NULL, 0);
+
+ /* Load the main file's symbols. */
symbol_file_add_main (execd_pathname, 0);
- /* Reset the shared library package. This ensures that we get
- a shlib event when the child reaches "_start", at which point
- the dld will have had a chance to initialize the child. */
- no_shared_libraries (NULL, 0);
#ifdef SOLIB_CREATE_INFERIOR_HOOK
SOLIB_CREATE_INFERIOR_HOOK (PIDGET (inferior_ptid));
#else