Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Nick Clifton <nickc@redhat.com>
To: carlton@math.stanford.edu, ac131313@redhat.com
Cc: gdb <gdb@sources.redhat.com>, binutils@sources.redhat.com
Subject: Re: gdb.mi/mi-cli.exp failures
Date: Tue, 01 Apr 2003 10:18:00 -0000	[thread overview]
Message-ID: <m3brzqzfn5.fsf@workshop.nickc.cambridge.redhat.com> (raw)
In-Reply-To: <3E88AE3F.4030005@redhat.com>

Hi Andrew, Hi David

> > FYI, my test run from my just committed call_dummy_p change had
> > the usual 21 failures.  Yet, mysteriously, for my next set of
> > patches, I'm seeing the failures jump to 28. While I'll note that
> > I'm the prime suspect, did anything else get changed?

Which 21 vs 28 failures are these ?  (I could reproduce the mi-cli.exp
failure, but I do not know if this is the problem Andrew was
referring to).


> Applying the attached to BFD fixes the problem ....

Although applying it would be a bad idea because it reverts several
bug fixes that plug memory leaks.

Instead here is a version that removes the use of "concat()" inside
dwarf2.c:concat_filename() which is a good thing, but which probably
does not solve the problem that you encountered in GDB.

Can you narrow down which part of David Heine's patch (altered by me)
is causing you problems, or tell me which tests in GDB are now failing
so that I can try to track it down myself.

Cheers
        Nick

2003-04-01  Nick Clifton  <nickc@redhat.com>

	* dwarf2.c (concat_filename): Use bfd_malloc() and strdup()
	instead of concat().
	(decode_line_info): Only free filename if it is not NULL.

Index: bfd/dwarf2.c
===================================================================
RCS file: /cvs/src/src/bfd/dwarf2.c,v
retrieving revision 1.44
diff -c -3 -p -w -r1.44 dwarf2.c
*** bfd/dwarf2.c	1 Apr 2003 00:12:12 -0000	1.44
--- bfd/dwarf2.c	1 Apr 2003 10:13:15 -0000
*************** add_line_info (table, address, filename,
*** 908,914 ****
  }
  
  /* Extract a fully qualified filename from a line info table.
!    The returned string has been xmalloc'ed.  */
  
  static char *
  concat_filename (table, file)
--- 908,915 ----
  }
  
  /* Extract a fully qualified filename from a line info table.
!    The returned string has been malloc'ed and it is the caller's
!    responsibility to free it.  */
  
  static char *
  concat_filename (table, file)
*************** concat_filename (table, file)
*** 921,946 ****
      {
        (*_bfd_error_handler)
  	(_("Dwarf Error: mangled line number section (bad file number)."));
!       return concat ("<unknown>");
      }
  
    filename = table->files[file - 1].name;
  
!   if (IS_ABSOLUTE_PATH (filename))
!     return concat (filename);
!   else
      {
        char* dirname = (table->files[file - 1].dir
  		       ? table->dirs[table->files[file - 1].dir - 1]
  		       : table->comp_dir);
  
!       /* Not all tools set DW_AT_comp_dir, so dirname may be unknown.  The
! 	 best we can do is return the filename part.  */
!       if (dirname == NULL)
! 	return concat (filename);
!       else
! 	return concat (dirname, "/", filename, NULL);
      }
  }
  
  static void
--- 922,953 ----
      {
        (*_bfd_error_handler)
  	(_("Dwarf Error: mangled line number section (bad file number)."));
!       return strdup ("<unknown>");
      }
  
    filename = table->files[file - 1].name;
  
!   if (! IS_ABSOLUTE_PATH (filename))
      {
        char* dirname = (table->files[file - 1].dir
  		       ? table->dirs[table->files[file - 1].dir - 1]
  		       : table->comp_dir);
  
!       /* Not all tools set DW_AT_comp_dir, so dirname may be unknown.
! 	 The best we can do is return the filename part.  */
!       if (dirname != NULL)
! 	{
! 	  unsigned int len = strlen (dirname) + strlen (filename) + 2;
! 	  char * name;
! 
! 	  name = bfd_malloc (len);
! 	  if (name)
! 	    sprintf (name, "%s/%s", dirname, filename);
! 	  return name;
! 	}
      }
+ 
+   return strdup (filename);
  }
  
  static void
*************** decode_line_info (unit, stash)
*** 1266,1271 ****
--- 1273,1279 ----
  		   based, the references are 1 based.  */
  		file = read_unsigned_leb128 (abfd, line_ptr, &bytes_read);
  		line_ptr += bytes_read;
+ 		if (filename)
  		  free (filename);
  		filename = concat_filename (table, file);
  		break;
*************** decode_line_info (unit, stash)
*** 1302,1307 ****
--- 1310,1316 ----
  	    }
  	}
  
+       if (filename)
  	free (filename);
      }
  


  parent reply	other threads:[~2003-04-01 10:18 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-03-31 19:35 David Carlton
2003-03-31 20:22 ` Andrew Cagney
2003-03-31 21:08   ` Andrew Cagney
2003-03-31 21:20     ` Andrew Cagney
2003-04-01  1:09       ` Hans-Peter Nilsson
2003-04-01  1:38         ` Ian Lance Taylor
2003-04-01 10:18     ` Nick Clifton [this message]
2003-04-01 15:08       ` Andrew Cagney
2003-04-01 15:18         ` Daniel Jacobowitz
2003-04-01 16:22           ` Andrew Cagney
2003-04-01 16:34             ` Daniel Jacobowitz
2003-04-01 17:01               ` Andrew Cagney
2003-04-01 18:03                 ` Daniel Jacobowitz
     [not found]         ` <m31y0mxk8i.fsf@workshop.nickc.cambridge.redhat.com>
2003-04-01 17:09           ` Andrew Cagney
2003-04-01 18:23             ` Daniel Jacobowitz
2003-04-02 17:06               ` Nick Clifton
2003-04-02 17:13                 ` Daniel Jacobowitz
2003-04-02 17:21                 ` Ian Lance Taylor
2003-04-02 17:28                   ` Daniel Jacobowitz
2003-04-02 17:44                     ` Ian Lance Taylor
2003-04-02 18:05                       ` Daniel Jacobowitz
2003-04-02 20:39                         ` Ian Lance Taylor
2003-04-02 20:38                           ` Daniel Jacobowitz
2003-04-02 20:53                             ` Ian Lance Taylor

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=m3brzqzfn5.fsf@workshop.nickc.cambridge.redhat.com \
    --to=nickc@redhat.com \
    --cc=ac131313@redhat.com \
    --cc=binutils@sources.redhat.com \
    --cc=carlton@math.stanford.edu \
    --cc=gdb@sources.redhat.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