Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
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	[thread overview]
Message-ID: <87hexzaozu.fsf@dynamic-addr-83-177.resnet.rochester.edu> (raw)
In-Reply-To: <npofs8kkel.fsf@zwingli.cygnus.com>

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


  parent reply	other threads:[~2001-06-01 14:07 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-05-30 14:27 Charlie Mills
2001-05-30 14:36 ` Christopher Faylor
2001-05-30 15:16   ` Fernando Nasser
2001-05-30 20:18     ` Jim Blandy
2001-05-30 20:25       ` Christopher Faylor
2001-05-31  5:30       ` Fernando Nasser
2001-05-31 13:55         ` Jim Blandy
2001-05-31 14:43           ` Fernando Nasser
2001-05-31 16:46           ` Christopher Faylor
2001-05-31 17:40             ` Daniel Berlin
2001-05-31 20:00               ` Frank Ch. Eigler
2001-06-01  9:41                 ` Fernando Nasser
2001-06-01 10:01                 ` Michael Snyder
2001-06-01 11:14                   ` Daniel Berlin
2001-06-01 11:25                     ` Fernando Nasser
2001-06-01 14:05                       ` Charlie Mills
2001-06-06  6:01                 ` Andrew Cagney
2001-05-30 20:00   ` Christopher Faylor
2001-05-30 20:43     ` Christopher Faylor
2001-05-30 20:12 ` Jim Blandy
2001-05-30 21:23   ` Daniel Berlin
2001-06-01 13:35 ` Jim Blandy
2001-06-01 13:41   ` Fernando Nasser
2001-06-01 14:07   ` Daniel Berlin [this message]
2001-06-01 14:15     ` Jim Blandy
2001-06-01 14:17     ` Jim Blandy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87hexzaozu.fsf@dynamic-addr-83-177.resnet.rochester.edu \
    --to=dan@cgsoftware.com \
    --cc=cmills@synopsys.com \
    --cc=gdb-patches@sourceware.cygnus.com \
    --cc=jimb@zwingli.cygnus.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox