From mboxrd@z Thu Jan  1 00:00:00 1970
From: Daniel Berlin <dan@cgsoftware.com>
To: Jim Blandy <jimb@zwingli.cygnus.com>
Cc: Charlie Mills <cmills@synopsys.com>, gdb-patches@sourceware.cygnus.com
Subject: Re: Simple but crucial bug fix to gdb
Date: Fri, 01 Jun 2001 14:07:00 -0000
Message-id: <87hexzaozu.fsf@dynamic-addr-83-177.resnet.rochester.edu>
References: <3.0.5.32.20010530142745.01470ec0@pophost.pdxuxbre.lmc.com> <npofs8kkel.fsf@zwingli.cygnus.com>
X-SW-Source: 2001-06/msg00011.html

Jim Blandy <jimb@zwingli.cygnus.com> writes:

> Charlie Mills <cmills@synopsys.com> writes:
> > Bug description:  gdb 4.xx and 5.0 crashes while reading our executable.
> > Our executable is the result of linking objects compiled by gcc with
> > other objects compiled using SPARCworks CC.  The stack trace is
> > appended at the end of this message.
> 
> I managed to construct an executable that would crash GDB in the same
> way yours did (by editing a binary to get stabs of the sort Sun's
> compiler produces).  I'm committing the patch below, which prevents
> the crashes.  It's essentially the same fix as yours, except that
> there are two cases (static and global functions) that need attention,
> not one.
> 
> I'm concerned that your builds are producing debugging entries for
> functions that appear to be outside of any compilation unit.  GDB
> doesn't really know what to do with this; at the moment, it mostly
> ignores the function's entry.  I wish I could play around with the
> situation and figure out what really needs to be done; with the
> current fix, I strongly suspect that GDB will be unable to find
> debugging information for some functions in some circumstances.  So
> that the problem doesn't disappear from view entirely, my patch makes
> GDB complain (that's a technical term) when it sees debugging info
> like that present in your executable.  Perhaps we'll find another
> case, and we'll be able to really fix the bug.

One nit in the patch below:

> 
> In any case, thanks for the bug report.
> 
> 2001-06-01  Jim Blandy  <jimb@redhat.com>
> 
> 	* partial-stab.h: New complaint: function_outside_compilation_unit.
> 	(case N_FUN: case 'f':, case N_FUN: case 'F':): If pst is zero,
> 	complain, and don't try to set pst's start address.
> 
> Index: gdb/partial-stab.h
> ===================================================================
> RCS file: /cvs/src/src/gdb/partial-stab.h,v
> retrieving revision 1.9
> diff -c -r1.9 partial-stab.h
> *** gdb/partial-stab.h	2001/05/31 03:41:31	1.9
> --- gdb/partial-stab.h	2001/06/01 20:24:26
> ***************
> *** 40,45 ****
> --- 40,48 ----
>   
>   switch (CUR_SYMBOL_TYPE)
>     {
> +     static struct complaint function_outside_compilation_unit = {
> +       "function `%s' appears to be defined outside of all compilation units", 0, 0
> +     };
>       char *p;
>       /*
>        * Standard, external, non-debugger, symbols
> ***************
> *** 576,581 ****
> --- 579,592 ----
>   	continue;
>   
>         case 'f':
> +         if (! pst)
> +           {
> +             int name_len = p - namestring;
> +             char *name = xmalloc (name_len + 1);
> +             memcpy (name, namestring, name_len);
> +             name[name_len] = '\0';
> +             complain (&function_outside_compilation_unit, name);

Err, isn't this a memory leak?

You never free the name after complaining.

Same below

-- 
"Why is the alphabet in that order?  Is it because of that song?
The guy who wrote that song wrote everything.
"-Steven Wright