This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]