[RFA/hpux] SEGV when running program using dlopen

[RFA/hpux] SEGV when running program using dlopen

[Joel Brobecker]

[-- Attachment #1: Type: text/plain, Size: 2560 bytes --]

This is on HP/UX 11.00.

Compile the following little program:

    #include <stdio.h>
    #include <dl.h>
    
    int
    main (void)
    {
      void * o = shl_load ("/usr/lib/libnss_files.1", BIND_IMMEDIATE, 0L);
    
      printf ("Got o = %p\n", o);
    
      shl_unload (o);
    
      return 0;
    }

With this command:

        % gcc -g -o dl dl.c /opt/langtools/lib/end.o

Now try to run the program under the debugger:

        % gdb dl
        (gdb) run
        Starting program: /[...]/dl

        Program received signal SIGSEGV, Segmentation fault.
        0xc08ee090 in ?? ()

The expected behavior is:

        (gdb) run
        Starting program: /[...]/dl 
        Got o = 7b03d180
        
        Program exited normally.

The problem is in solib-som.c:som_solib_create_inferior_hook(): We're
looking up the address of __d_trap, and end up finding the address of
the function. But we need the stub, not the function. So we have the
following code that tries to do that:

  /* Grrr, this might not be an export symbol!  We have to find the
     export stub.  */
  ALL_OBJFILES (objfile)
  {
    struct unwind_table_entry *u;
    struct minimal_symbol *msymbol2;

    /* What a crock.  */
    msymbol2 =
      lookup_minimal_symbol_solib_trampoline (SYMBOL_LINKAGE_NAME (msymbol),
                                              objfile);
    /* Found a symbol with the right name.  */
    if (msymbol2)
      {
        struct unwind_table_entry *u;
        /* It must be a shared library trampoline.  */
        if (SYMBOL_TYPE (msymbol2) != mst_solib_trampoline)
          continue;

        /* It must also be an export stub.  */
        u = find_unwind_entry (SYMBOL_VALUE (msymbol2));
        if (!u || u->stub_unwind.stub_type != EXPORT)
          continue;

        /* OK.  Looks like the correct import stub.  */
        anaddr = SYMBOL_VALUE (msymbol2);
        dld_cache.hook_stub.address = anaddr;
      }
  }

Unfortunately for us, that doesnt' work for __d_trap, as that symbol
lives in crt0. So lookup_minimal_symbol_solib_trampoline never returns
any match, and we end up stuck with the non-stub address.

I replaced the above block by a simply ALL_MSYMBOLS loop that simply
matches the msymbol name before checking for the associated stub type.
That fixes the problem.

2004-12-15  Joel Brobecker  <brobecker@gnat.com>

        * solib-som.c (som_solib_create_inferior_hook): Extend stub
        msymbol search to all objfiles, not just shared libraries.

Tested on HP/UX 11.00, no regression.
OK to commit?

Thanks,
-- 
Joel

[-- Attachment #2: solib-som.c.diff --]
[-- Type: text/plain, Size: 2085 bytes --]

Index: solib-som.c
===================================================================
RCS file: /cvs/src/src/gdb/solib-som.c,v
retrieving revision 1.1
diff -u -p -r1.1 solib-som.c
--- solib-som.c	8 Dec 2004 01:36:42 -0000	1.1
+++ solib-som.c	15 Dec 2004 07:30:02 -0000
@@ -157,7 +157,7 @@ som_relocate_section_addresses (struct s
 static void
 som_solib_create_inferior_hook (void)
 {
-  struct minimal_symbol *msymbol;
+  struct minimal_symbol *msymbol, *msymbol2;
   unsigned int dld_flags, status, have_endo;
   asection *shlib_info;
   char buf[4];
@@ -226,33 +226,22 @@ som_solib_create_inferior_hook (void)
 
   /* Grrr, this might not be an export symbol!  We have to find the
      export stub.  */
-  ALL_OBJFILES (objfile)
-  {
-    struct unwind_table_entry *u;
-    struct minimal_symbol *msymbol2;
-
-    /* What a crock.  */
-    msymbol2 =
-      lookup_minimal_symbol_solib_trampoline (SYMBOL_LINKAGE_NAME (msymbol),
-					      objfile);
-    /* Found a symbol with the right name.  */
-    if (msymbol2)
-      {
-	struct unwind_table_entry *u;
-	/* It must be a shared library trampoline.  */
-	if (SYMBOL_TYPE (msymbol2) != mst_solib_trampoline)
-	  continue;
-
-	/* It must also be an export stub.  */
-	u = find_unwind_entry (SYMBOL_VALUE (msymbol2));
-	if (!u || u->stub_unwind.stub_type != EXPORT)
-	  continue;
-
-	/* OK.  Looks like the correct import stub.  */
-	anaddr = SYMBOL_VALUE (msymbol2);
-	dld_cache.hook_stub.address = anaddr;
-      }
-  }
+  ALL_MSYMBOLS (objfile, msymbol2)
+    {
+      if (strcmp (SYMBOL_LINKAGE_NAME (msymbol2),
+                  SYMBOL_LINKAGE_NAME (msymbol)) == 0)
+        {
+          struct unwind_table_entry *u;
+
+          u = find_unwind_entry (SYMBOL_VALUE (msymbol2));
+          if (u != NULL && u->stub_unwind.stub_type == EXPORT)
+            {
+	      anaddr = SYMBOL_VALUE (msymbol2);
+	      dld_cache.hook_stub.address = anaddr;
+              break;
+            }
+        }
+    }
   store_unsigned_integer (buf, 4, anaddr);
 
   msymbol = lookup_minimal_symbol ("__dld_hook", NULL, symfile_objfile);

Re: [RFA/hpux] SEGV when running program using dlopen

[Randolph Chung]

> Unfortunately for us, that doesnt' work for __d_trap, as that symbol
> lives in crt0. So lookup_minimal_symbol_solib_trampoline never returns
> any match, and we end up stuck with the non-stub address.
> 
> I replaced the above block by a simply ALL_MSYMBOLS loop that simply
> matches the msymbol name before checking for the associated stub type.
> That fixes the problem.

hrm, a question:

since we are already doing this in an ALL_OBJFILES loop, how come we
don't find the right symbol? i also notice that the problem only occurs
when you link in end.o; what does that do?

that kind of a loop exists elsewhere for the hpux target, so i want to
understand this a bit more.

thanks
randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

Re: [RFA/hpux] SEGV when running program using dlopen

[Joel Brobecker]

> since we are already doing this in an ALL_OBJFILES loop, how come we
> don't find the right symbol?

The answer is in the body of lookup_minimal_symbol_solib_trampoline().

It iterates over all msymbols of the objfile, and returns the first
one whose name matches *and* whose ``MSYMBOL_TYPE (msymbol) ==
mst_solib_trampoline''. See minsyms.c, around line 353.

Since in our case, the symbol we're looking for is not inside
a shared library, the lookup always fails.

I was also wondering whether the current code might be working
by pure luck in the other case. Assuming that the objfile contains
two symbols (one stub, one function) in the shared library, what
guaranty do we have that the lookup will find the one we're looking
for?

> i also notice that the problem only occurs when you link in end.o;
> what does that do?

AFAIK, it provides some help in debugging by exporting some specified
symbols. The only use I know of if with shared libraries...

-- 
Joel

Re: [RFA/hpux] SEGV when running program using dlopen

[Randolph Chung]

> The answer is in the body of lookup_minimal_symbol_solib_trampoline().
> 
> It iterates over all msymbols of the objfile, and returns the first
> one whose name matches *and* whose ``MSYMBOL_TYPE (msymbol) ==
> mst_solib_trampoline''. See minsyms.c, around line 353.
> 
> Since in our case, the symbol we're looking for is not inside
> a shared library, the lookup always fails.

hrm, i see....

> I was also wondering whether the current code might be working
> by pure luck in the other case. Assuming that the objfile contains
> two symbols (one stub, one function) in the shared library, what
> guaranty do we have that the lookup will find the one we're looking
> for?

yeah, seems a bit bogus :) i think it works only because export stubs
normally occur earlier in a file than the real function; but i suppose
that doesn't have to be the case.

> AFAIK, it provides some help in debugging by exporting some specified
> symbols. The only use I know of if with shared libraries...

ok, thanks. your patch looks good; i'm still wondering if we should have
unified logic to search for (export|import) stubs... but that's for
later.

thanks,
randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

Re: [RFA/hpux] SEGV when running program using dlopen

[Joel Brobecker]

> yeah, seems a bit bogus :) i think it works only because export stubs
> normally occur earlier in a file than the real function; but i suppose
> that doesn't have to be the case.

Either that, or the ordering of the symbols in our data structures can
change.

> > AFAIK, it provides some help in debugging by exporting some specified
> > symbols. The only use I know of if with shared libraries...
> 
> ok, thanks. your patch looks good; i'm still wondering if we should have
> unified logic to search for (export|import) stubs... but that's for
> later.

I thought about this too, actually. I think it's a great idea. The
patch will be slightly larger, but I can export the new code into
a function and call that. Might be useful elsewhere, and will make
the code a bit cleaner in any case.

If you prefer, you can also take my patch, adapt it, and do the commit.

-- 
Joel (GMT + 4, so time to sign off)

Re: [RFA/hpux] SEGV when running program using dlopen

[Joel Brobecker]

[-- Attachment #1: Type: text/plain, Size: 659 bytes --]

> ok, thanks. your patch looks good; i'm still wondering if we should have
> unified logic to search for (export|import) stubs... but that's for
> later.

How is the following?

2004-12-17  Joel Brobecker  <brobecker@gnat.com>

        * hppa-tdep.c (hppa_lookup_stub_minimal_symbol): New function.
        * hppa-tdep.h (hppa_lookup_stub_minimal_symbol): Add declaration.
        * solib-som.c (som_solib_create_inferior_hook): Replace stub
        msymbol search by call to hppa_lookup_stub_minimal_symbol. This
        extends the search to all objfiles, not just shared libraries.
        Remove unused variable.

Tested on HP/UX 11.00.

Thanks,
-- 
Joel

[-- Attachment #2: solib.diff --]
[-- Type: text/plain, Size: 3641 bytes --]

Index: hppa-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/hppa-tdep.c,v
retrieving revision 1.192
diff -u -p -r1.192 hppa-tdep.c
--- hppa-tdep.c	14 Dec 2004 16:35:37 -0000	1.192
+++ hppa-tdep.c	17 Dec 2004 06:49:05 -0000
@@ -2255,6 +2255,31 @@ hppa_unwind_pc (struct gdbarch *gdbarch,
   return pc & ~0x3;
 }
 
+/* Return the minimal symbol whose name is NAME and stub type is STUB_TYPE.
+   Return NULL if no such symbol was found.  */
+
+extern struct minimal_symbol *
+hppa_lookup_stub_minimal_symbol (const char *name,
+                                 enum unwind_stub_types stub_type)
+{
+  struct objfile *objfile;
+  struct minimal_symbol *msym;
+
+  ALL_MSYMBOLS (objfile, msym)
+    {
+      if (strcmp (SYMBOL_LINKAGE_NAME (msym), name) == 0)
+        {
+          struct unwind_table_entry *u;
+
+          u = find_unwind_entry (SYMBOL_VALUE (msym));
+          if (u != NULL && u->stub_unwind.stub_type == stub_type)
+            return msym;
+        }
+    }
+
+  return NULL;
+}
+
 /* Instead of this nasty cast, add a method pvoid() that prints out a
    host VOID data type (remember %p isn't portable).  */
 
Index: hppa-tdep.h
===================================================================
RCS file: /cvs/src/src/gdb/hppa-tdep.h,v
retrieving revision 1.17
diff -u -p -r1.17 hppa-tdep.h
--- hppa-tdep.h	13 Dec 2004 04:06:15 -0000	1.17
+++ hppa-tdep.h	17 Dec 2004 06:49:05 -0000
@@ -231,4 +231,8 @@ extern void hppa_write_pc (CORE_ADDR pc,
 extern CORE_ADDR hppa_unwind_pc (struct gdbarch *gdbarch,
 				 struct frame_info *next_frame);
 
+extern struct minimal_symbol *
+  hppa_lookup_stub_minimal_symbol (const char *name,
+                                   enum unwind_stub_types stub_type);
+
 #endif  /* HPPA_TDEP_H */
Index: solib-som.c
===================================================================
RCS file: /cvs/src/src/gdb/solib-som.c,v
retrieving revision 1.1
diff -u -p -r1.1 solib-som.c
--- solib-som.c	8 Dec 2004 01:36:42 -0000	1.1
+++ solib-som.c	17 Dec 2004 06:49:06 -0000
@@ -161,7 +161,6 @@ som_solib_create_inferior_hook (void)
   unsigned int dld_flags, status, have_endo;
   asection *shlib_info;
   char buf[4];
-  struct objfile *objfile;
   CORE_ADDR anaddr;
 
   /* First, remove all the solib event breakpoints.  Their addresses
@@ -226,33 +225,13 @@ som_solib_create_inferior_hook (void)
 
   /* Grrr, this might not be an export symbol!  We have to find the
      export stub.  */
-  ALL_OBJFILES (objfile)
-  {
-    struct unwind_table_entry *u;
-    struct minimal_symbol *msymbol2;
-
-    /* What a crock.  */
-    msymbol2 =
-      lookup_minimal_symbol_solib_trampoline (SYMBOL_LINKAGE_NAME (msymbol),
-					      objfile);
-    /* Found a symbol with the right name.  */
-    if (msymbol2)
-      {
-	struct unwind_table_entry *u;
-	/* It must be a shared library trampoline.  */
-	if (SYMBOL_TYPE (msymbol2) != mst_solib_trampoline)
-	  continue;
-
-	/* It must also be an export stub.  */
-	u = find_unwind_entry (SYMBOL_VALUE (msymbol2));
-	if (!u || u->stub_unwind.stub_type != EXPORT)
-	  continue;
-
-	/* OK.  Looks like the correct import stub.  */
-	anaddr = SYMBOL_VALUE (msymbol2);
-	dld_cache.hook_stub.address = anaddr;
-      }
-  }
+  msymbol = hppa_lookup_stub_minimal_symbol (SYMBOL_LINKAGE_NAME (msymbol),
+                                             EXPORT);
+  if (msymbol != NULL)
+    {
+      anaddr = SYMBOL_VALUE (msymbol);
+      dld_cache.hook_stub.address = anaddr;
+    }
   store_unsigned_integer (buf, 4, anaddr);
 
   msymbol = lookup_minimal_symbol ("__dld_hook", NULL, symfile_objfile);

Re: [RFA/hpux] SEGV when running program using dlopen

[Randolph Chung]

> How is the following?

can you get rid of the "extern" from:

(hppa-tdep.c)
> +extern struct minimal_symbol *
> +hppa_lookup_stub_minimal_symbol (const char *name,
> +                                 enum unwind_stub_types stub_type)

?

looks good to me otherwise.

thanks
randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

Re: [RFA/hpux] SEGV when running program using dlopen

[Joel Brobecker]

> can you get rid of the "extern" from:
> 
> (hppa-tdep.c)
> > +extern struct minimal_symbol *
> > +hppa_lookup_stub_minimal_symbol (const char *name,
> > +                                 enum unwind_stub_types stub_type)
> 
> ?
> 
> looks good to me otherwise.

Ah, ooops, yes, of course.

Checked in.

Thanks,
-- 
Joel