Interesting dwarf-2/shared lib problem.

Interesting dwarf-2/shared lib problem.

[Kris Warkentin]

When debugging an app with a shared lib I ran across the following problem.

After having proceeded to main(), all libs/syms are loaded, source search
directory set appropriately, etc.

Trying to use the following address form:

list display.c:10
-or-
break display.c:27

where display.c is in one of the loaded shared libraries, fails with "No
source file named display.c"

If I then do "break display", where display() is a function in display.c,
the above two addressing forms work fine.

I observed that libdisplay.so has been loaded with a psymtab and that the
code in lookup_symtab() only searches through objects which have a full
symtab loaded.  This would seem to be why it's not finding display.c.  I'm
supposing that when you do a break on a function, the full symtab is then
loaded.

Note also that this goes away if the source is compiled with the stabs+
debugging format.  I'm pondering the solution to this.  Is there a way to
force gdb to load the full symbol table for all shared objects?  Or is there
a better way to get around this?

cheers,

Kris

Re: Interesting dwarf-2/shared lib problem.

[Daniel Jacobowitz]

On Tue, Dec 02, 2003 at 11:13:53AM -0500, Kris Warkentin wrote:
> When debugging an app with a shared lib I ran across the following problem.
> 
> After having proceeded to main(), all libs/syms are loaded, source search
> directory set appropriately, etc.
> 
> Trying to use the following address form:
> 
> list display.c:10
> -or-
> break display.c:27
> 
> where display.c is in one of the loaded shared libraries, fails with "No
> source file named display.c"
> 
> If I then do "break display", where display() is a function in display.c,
> the above two addressing forms work fine.
> 
> I observed that libdisplay.so has been loaded with a psymtab and that the
> code in lookup_symtab() only searches through objects which have a full
> symtab loaded.  This would seem to be why it's not finding display.c.  I'm
> supposing that when you do a break on a function, the full symtab is then
> loaded.
> 
> Note also that this goes away if the source is compiled with the stabs+
> debugging format.  I'm pondering the solution to this.  Is there a way to
> force gdb to load the full symbol table for all shared objects?  Or is there
> a better way to get around this?

From lookup_symtab:
  /* Same search rules as above apply here, but now we look thru the
     psymtabs.  */

  ps = lookup_partial_symtab (name);
  if (!ps)
    return (NULL);

Is that not working?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: Interesting dwarf-2/shared lib problem.

[Kris Warkentin]

> > I observed that libdisplay.so has been loaded with a psymtab and that
the
> > code in lookup_symtab() only searches through objects which have a full
> > symtab loaded.  This would seem to be why it's not finding display.c.
I'm
> > supposing that when you do a break on a function, the full symtab is
then
> > loaded.
> >
> > Note also that this goes away if the source is compiled with the stabs+
> > debugging format.  I'm pondering the solution to this.  Is there a way
to
> > force gdb to load the full symbol table for all shared objects?  Or is
there
> > a better way to get around this?
>
> >From lookup_symtab:
>   /* Same search rules as above apply here, but now we look thru the
>      psymtabs.  */
>
>   ps = lookup_partial_symtab (name);
>   if (!ps)
>     return (NULL);
>
> Is that not working?

Ah...interesting.  For the main object, the symtab points to
c:\some_dir\main.c and the symtab->next points to just main.c.  It's the
main.c that gets caught and returned.  In the solib, we only see the
c:\some_lib\display.c so the FILENAME_CMP fails..

So you are correct, lookup_partial_symtab is failing.

cheers,

Kris

Re: Interesting dwarf-2/shared lib problem.

[Kris Warkentin]

> Ah...interesting.  For the main object, the symtab points to
> c:\some_dir\main.c and the symtab->next points to just main.c.  It's the
> main.c that gets caught and returned.  In the solib, we only see the
> c:\some_lib\display.c so the FILENAME_CMP fails..
>
> So you are correct, lookup_partial_symtab is failing.

Looks like lbasename() in libiberty/lbasename.c is failing.  The
IS_DIR_SEPARATOR macro isn't being defined for __CYGWIN__ so when we've
compiled something with dos style paths...you get the picture.  I fixed it
in our source but someone might want to ponder this....

Index: lbasename.c
===================================================================
RCS file: /product/tools/gdb/libiberty/lbasename.c,v
retrieving revision 1.2
diff -u -r1.2 lbasename.c
--- lbasename.c 6 Sep 2002 20:21:02 -0000       1.2
+++ lbasename.c 2 Dec 2003 17:10:58 -0000
@@ -46,7 +46,7 @@
 #endif

 #if defined (_WIN32) || defined (__MSDOS__) \
-    || defined (__DJGPP__) || defined (__OS2__)
+    || defined (__DJGPP__) || defined (__OS2__) || defined (__CYGWIN__)
 #  define HAVE_DOS_BASED_FILE_SYSTEM
 #  ifndef DIR_SEPARATOR_2
 #    define DIR_SEPARATOR_2 '\\'

cheers,

Kris

Re: Interesting dwarf-2/shared lib problem.

[Daniel Jacobowitz]

On Tue, Dec 02, 2003 at 12:12:49PM -0500, Kris Warkentin wrote:
> > Ah...interesting.  For the main object, the symtab points to
> > c:\some_dir\main.c and the symtab->next points to just main.c.  It's the
> > main.c that gets caught and returned.  In the solib, we only see the
> > c:\some_lib\display.c so the FILENAME_CMP fails..
> >
> > So you are correct, lookup_partial_symtab is failing.
> 
> Looks like lbasename() in libiberty/lbasename.c is failing.  The
> IS_DIR_SEPARATOR macro isn't being defined for __CYGWIN__ so when we've
> compiled something with dos style paths...you get the picture.  I fixed it
> in our source but someone might want to ponder this....

Blast, more out-of-sync copies of this.  That one's my fault.  This
ought to come from include/filenames.h now.

Could you file a report in the GCC bugzilla system about this and
assign it to me?  GCC is the master for this file.

> Index: lbasename.c
> ===================================================================
> RCS file: /product/tools/gdb/libiberty/lbasename.c,v
> retrieving revision 1.2
> diff -u -r1.2 lbasename.c
> --- lbasename.c 6 Sep 2002 20:21:02 -0000       1.2
> +++ lbasename.c 2 Dec 2003 17:10:58 -0000
> @@ -46,7 +46,7 @@
>  #endif
> 
>  #if defined (_WIN32) || defined (__MSDOS__) \
> -    || defined (__DJGPP__) || defined (__OS2__)
> +    || defined (__DJGPP__) || defined (__OS2__) || defined (__CYGWIN__)
>  #  define HAVE_DOS_BASED_FILE_SYSTEM
>  #  ifndef DIR_SEPARATOR_2
>  #    define DIR_SEPARATOR_2 '\\'
> 
> cheers,
> 
> Kris
> 
> 
> 

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer