[RFC/RFA] Deal with -g1 generated DWARF2 debug info

[RFC/RFA] Deal with -g1 generated DWARF2 debug info

[Mark Kettenis]

In an attempt to improve backtraces in bug reports, we now build
libraries with -g1 on OpenBSD.  This revealed an interesting gdb
issue.  A few testsuite tests now FAILed with:

   No memory available to program: call to malloc failed

That's pretty annoying, since it makes passing strings to C functions
basicallt impossible.  I noticed that where previously we had:

(gdb) ptype malloc
type = int ()

with -g1 we get:

(gdb) ptype malloc
type = void ()

As a result GDB thinks there is no return value from malloc and things
the malloc call failed.

The cause of the problem is that DWARF2 doesn't really have the
possibility to indicate that it doesn't know the return type of a
function.  The absence of DW_AT_type for a DW_TAG_subprogram indicates
a void function.  Indeed the debug info generated by -g1 for malloc
looks like:

$ readelf -wi /usr/lib/libc.so.38.4:
...
<1><af59>: Abbrev Number: 2 (DW_TAG_subprogram)
     DW_AT_name        : (indirect string, offset: 0x6484): imalloc     
     DW_AT_decl_file   : 1      
     DW_AT_decl_line   : 1123   
     DW_AT_low_pc      : 0x67ca0        
     DW_AT_high_pc     : 0x67d9f        
     DW_AT_frame_base  : 1 byte block: 57       (DW_OP_reg7)
...

My proposal to deal with this issue is to check in
valops.c:find_function_in_inferior() whether the function is
prototyped or not.  If the function isn't prototyped, fall back on the
code that's already there that uses the minimal symbol info and
creates the return value type "by hand".

Mark


Index: ChangeLog
from  Mark Kettenis  <kettenis@gnu.org>

	* valops.c (find_function_in_inferior): Only use full symbol info
	if it is prototyped.

Index: valops.c
===================================================================
RCS file: /cvs/src/src/gdb/valops.c,v
retrieving revision 1.161
diff -u -p -r1.161 valops.c
--- valops.c 27 May 2005 04:39:32 -0000 1.161
+++ valops.c 4 Dec 2005 18:44:39 -0000
@@ -141,37 +141,36 @@ struct value *
 find_function_in_inferior (const char *name)
 {
   struct symbol *sym;
+  struct minimal_symbol *msymbol;
+
   sym = lookup_symbol (name, 0, VAR_DOMAIN, 0, NULL);
   if (sym != NULL)
     {
       if (SYMBOL_CLASS (sym) != LOC_BLOCK)
-	{
-	  error (_("\"%s\" exists in this program but is not a function."),
-		 name);
-	}
-      return value_of_variable (sym, NULL);
+	error (_("\"%s\" exists in this program but is not a function."),
+	       name);
+
+      if (TYPE_PROTOTYPED (SYMBOL_TYPE (sym)))
+	return value_of_variable (sym, NULL);
     }
-  else
+
+  msymbol = lookup_minimal_symbol (name, NULL, NULL);
+  if (msymbol != NULL)
     {
-      struct minimal_symbol *msymbol = lookup_minimal_symbol (name, NULL, NULL);
-      if (msymbol != NULL)
-	{
-	  struct type *type;
-	  CORE_ADDR maddr;
-	  type = lookup_pointer_type (builtin_type_char);
-	  type = lookup_function_type (type);
-	  type = lookup_pointer_type (type);
-	  maddr = SYMBOL_VALUE_ADDRESS (msymbol);
-	  return value_from_pointer (type, maddr);
-	}
-      else
-	{
-	  if (!target_has_execution)
-	    error (_("evaluation of this expression requires the target program to be active"));
-	  else
-	    error (_("evaluation of this expression requires the program to have a function \"%s\"."), name);
-	}
+      struct type *type;
+      CORE_ADDR maddr;
+
+      type = lookup_pointer_type (builtin_type_char);
+      type = lookup_function_type (type);
+      type = lookup_pointer_type (type);
+      maddr = SYMBOL_VALUE_ADDRESS (msymbol);
+      return value_from_pointer (type, maddr);
     }
+
+  if (!target_has_execution)
+    error (_("evaluation of this expression requires the target program to be active"));
+  else
+    error (_("evaluation of this expression requires the program to have a function \"%s\"."), name);
 }
 
 /* Allocate NBYTES of space in the inferior using the inferior's malloc

Re: [RFC/RFA] Deal with -g1 generated DWARF2 debug info

[Jim Blandy]

On 12/4/05, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
> a void function.  Indeed the debug info generated by -g1 for malloc
> looks like:
>
> $ readelf -wi /usr/lib/libc.so.38.4:
> ...
> <1><af59>: Abbrev Number: 2 (DW_TAG_subprogram)
>      DW_AT_name        : (indirect string, offset: 0x6484): imalloc
>      DW_AT_decl_file   : 1
>      DW_AT_decl_line   : 1123
>      DW_AT_low_pc      : 0x67ca0
>      DW_AT_high_pc     : 0x67d9f
>      DW_AT_frame_base  : 1 byte block: 57       (DW_OP_reg7)
> ...

That says "imalloc"; is that really what you meant to quote?

Re: [RFC/RFA] Deal with -g1 generated DWARF2 debug info

[Jim Blandy]

So, you want to have GDB misinterpret unambiguous Dwarf debugging info
so that you can use -g1?  This sounds like a good candidate for a
BSD-specific patch, to me.

Re: [RFC/RFA] Deal with -g1 generated DWARF2 debug info

[Daniel Jacobowitz]

On Sun, Dec 04, 2005 at 01:16:44PM -0800, Jim Blandy wrote:
> So, you want to have GDB misinterpret unambiguous Dwarf debugging info
> so that you can use -g1?  This sounds like a good candidate for a
> BSD-specific patch, to me.

I don't see why we care what the prototype for malloc in the debugging
information is.  We know the type of malloc.  A system which uses a
different type for malloc won't work here anyway.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: [RFC/RFA] Deal with -g1 generated DWARF2 debug info

[Jim Blandy]

On 12/4/05, Daniel Jacobowitz <drow@false.org> wrote:
> I don't see why we care what the prototype for malloc in the debugging
> information is.  We know the type of malloc.  A system which uses a
> different type for malloc won't work here anyway.

You mean, just ignore malloc's type altogether, and unconditionally
construct our own type?

I'd prefer that over Mark's patch, but this isn't great.  If malloc
has a bogus type, I think we should at least complain.  On
free-standing systems that might be real information.

The central issue here is that the compiler is emitting incorrect
debug info.  The GCC manual says of -g1:

     Level 1 produces minimal information, enough for making backtraces
     in parts of the program that you don't plan to debug.  This
     includes descriptions of functions and external variables, but no
     information about local variables and no line numbers.

Nothing there about reducing all return types to 'void'.

Re: [RFC/RFA] Deal with -g1 generated DWARF2 debug info

[Mark Kettenis]

> Date: Sun, 4 Dec 2005 13:12:41 -0800
> From: Jim Blandy <jimb@red-bean.com>
> 
> On 12/4/05, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
> > a void function.  Indeed the debug info generated by -g1 for malloc
> > looks like:
> >
> > $ readelf -wi /usr/lib/libc.so.38.4:
> > ...
> > <1><af59>: Abbrev Number: 2 (DW_TAG_subprogram)
> >      DW_AT_name        : (indirect string, offset: 0x6484): imalloc
> >      DW_AT_decl_file   : 1
> >      DW_AT_decl_line   : 1123
> >      DW_AT_low_pc      : 0x67ca0
> >      DW_AT_high_pc     : 0x67d9f
> >      DW_AT_frame_base  : 1 byte block: 57       (DW_OP_reg7)
> > ...
> 
> That says "imalloc"; is that really what you meant to quote?

Oops sorry, the entry for malloc isn't really different though:

 <1><afc1>: Abbrev Number: 3 (DW_TAG_subprogram)
     DW_AT_external    : 1      
     DW_AT_name        : (indirect string, offset: 0x6485): malloc      
     DW_AT_decl_file   : 1      
     DW_AT_decl_line   : 1762   
     DW_AT_low_pc      : 0x68250        
     DW_AT_high_pc     : 0x682ff        
     DW_AT_frame_base  : 1 byte block: 57       (DW_OP_reg7)

Mark

Re: [RFC/RFA] Deal with -g1 generated DWARF2 debug info

[Daniel Jacobowitz]

On Sun, Dec 04, 2005 at 02:00:21PM -0800, Jim Blandy wrote:
> On 12/4/05, Daniel Jacobowitz <drow@false.org> wrote:
> > I don't see why we care what the prototype for malloc in the debugging
> > information is.  We know the type of malloc.  A system which uses a
> > different type for malloc won't work here anyway.
> 
> You mean, just ignore malloc's type altogether, and unconditionally
> construct our own type?

Yes.

> I'd prefer that over Mark's patch, but this isn't great.  If malloc
> has a bogus type, I think we should at least complain.  On
> free-standing systems that might be real information.
> 
> The central issue here is that the compiler is emitting incorrect
> debug info.  The GCC manual says of -g1:
> 
>      Level 1 produces minimal information, enough for making backtraces
>      in parts of the program that you don't plan to debug.  This
>      includes descriptions of functions and external variables, but no
>      information about local variables and no line numbers.
> 
> Nothing there about reducing all return types to 'void'.

The compiler is buggy, but I object to any classification of this as a
BSD-specific change; it's GCC that's buggy and Debian used -g1 too for
a while.  It ICEs on some targets, and does this sort of thing.

Mark, FYI, we ended up removing all dwarf sections other than
.debug_frame.  This plus .symtab are enough to make backtraces useful;
it works quite well and avoids the undertested -g1.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: [RFC/RFA] Deal with -g1 generated DWARF2 debug info

[Mark Kettenis]

> Date: Sun, 4 Dec 2005 13:16:44 -0800
> From: Jim Blandy <jimb@red-bean.com>
> 
> So, you want to have GDB misinterpret unambiguous Dwarf debugging info
> so that you can use -g1?  This sounds like a good candidate for a
> BSD-specific patch, to me.

So people shouldn't try to compile glibc with -g1 on Linux or the
Hurd?  That'd result in a borked gdb as well.

You could argue that GCC is broken, but then given the constraints
laid out by the DWARF2 standard, what GCC does seems reasonable to me.

Mark

Re: [RFC/RFA] Deal with -g1 generated DWARF2 debug info

[Mark Kettenis]

> Date: Sun, 4 Dec 2005 14:00:21 -0800
> From: Jim Blandy <jimb@red-bean.com>
>
> The central issue here is that the compiler is emitting incorrect
> debug info.  The GCC manual says of -g1:
> 
>      Level 1 produces minimal information, enough for making backtraces
>      in parts of the program that you don't plan to debug.  This
>      includes descriptions of functions and external variables, but no
>      information about local variables and no line numbers.
> 
> Nothing there about reducing all return types to 'void'.

But fixing that would probably require that GCC dumps the complete
type info, which would reduce the usefulness of -g1.  And that doesn't
change the fact that GCC probably has been doing this for quite some
time now.

Re: [RFC/RFA] Deal with -g1 generated DWARF2 debug info

[Mark Kettenis]

> Date: Sun, 4 Dec 2005 17:15:47 -0500
> From: Daniel Jacobowitz <drow@false.org>
>
> The compiler is buggy, but I object to any classification of this as a
> BSD-specific change; it's GCC that's buggy and Debian used -g1 too for
> a while.  It ICEs on some targets, and does this sort of thing.
> 
> Mark, FYI, we ended up removing all dwarf sections other than
> .debug_frame.  This plus .symtab are enough to make backtraces useful;
> it works quite well and avoids the undertested -g1.

Hmm, perhaps we're just lucky, but it seems that all supported OpenBSD
platforms have no problem with -g1.  I'll keep your idea in mind as
plan B.  Doesn't it result in gdb printing the wrong function names
for static function names in backtraces?

Meanwhile, I still think that find_function_in_inferior() should be
fixed to deal with -g1.

Mark

Re: [RFC/RFA] Deal with -g1 generated DWARF2 debug info

[Daniel Jacobowitz]

On Sun, Dec 04, 2005 at 11:39:38PM +0100, Mark Kettenis wrote:
> > Date: Sun, 4 Dec 2005 17:15:47 -0500
> > From: Daniel Jacobowitz <drow@false.org>
> >
> > The compiler is buggy, but I object to any classification of this as a
> > BSD-specific change; it's GCC that's buggy and Debian used -g1 too for
> > a while.  It ICEs on some targets, and does this sort of thing.
> > 
> > Mark, FYI, we ended up removing all dwarf sections other than
> > .debug_frame.  This plus .symtab are enough to make backtraces useful;
> > it works quite well and avoids the undertested -g1.
> 
> Hmm, perhaps we're just lucky, but it seems that all supported OpenBSD
> platforms have no problem with -g1.  I'll keep your idea in mind as
> plan B.  Doesn't it result in gdb printing the wrong function names
> for static function names in backtraces?

No.  It gets those from .symtab; that's why we left it in.

> Meanwhile, I still think that find_function_in_inferior() should be
> fixed to deal with -g1.

I'm uncertain.  What GCC is producing is definitely wrong.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: [RFC/RFA] Deal with -g1 generated DWARF2 debug info

[Daniel Jacobowitz]

On Sun, Dec 04, 2005 at 11:30:48PM +0100, Mark Kettenis wrote:
> > Date: Sun, 4 Dec 2005 14:00:21 -0800
> > From: Jim Blandy <jimb@red-bean.com>
> >
> > The central issue here is that the compiler is emitting incorrect
> > debug info.  The GCC manual says of -g1:
> > 
> >      Level 1 produces minimal information, enough for making backtraces
> >      in parts of the program that you don't plan to debug.  This
> >      includes descriptions of functions and external variables, but no
> >      information about local variables and no line numbers.
> > 
> > Nothing there about reducing all return types to 'void'.
> 
> But fixing that would probably require that GCC dumps the complete
> type info, which would reduce the usefulness of -g1.  And that doesn't
> change the fact that GCC probably has been doing this for quite some
> time now.

Except, no one seems to _use_ .debug_info with -g1... Why do you want
information about functions, if it's not going to tell you anything
that wasn't in the symbol table?

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: [RFC/RFA] Deal with -g1 generated DWARF2 debug info

[Mark Kettenis]

> Date: Sun, 4 Dec 2005 18:06:46 -0500
> From: Daniel Jacobowitz <drow@false.org>
>
> > > Mark, FYI, we ended up removing all dwarf sections other than
> > > .debug_frame.  This plus .symtab are enough to make backtraces useful;
> > > it works quite well and avoids the undertested -g1.
> > 
> > Hmm, perhaps we're just lucky, but it seems that all supported OpenBSD
> > platforms have no problem with -g1.  I'll keep your idea in mind as
> > plan B.  Doesn't it result in gdb printing the wrong function names
> > for static function names in backtraces?
> 
> No.  It gets those from .symtab; that's why we left it in.

Bleah, turns out we were using ld -x on the object files before
building them into a library.  Of course this made local symbols
disappear from .symtab.

Anyway, it seems that my fellow OpenBSD developers are happy with
compiling all system libraries with -g, which of course is much better
;-).

I'll send a message to the GCC mailing list about -g1 & DWARF2.

Mark