From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-11778-listarch-gdb=sources.redhat.com@sources.redhat.com>
Received: (qmail 7762 invoked by alias); 8 Jan 2003 20:46:35 -0000
Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm
Precedence: bulk
List-Subscribe: <mailto:gdb-subscribe@sources.redhat.com>
List-Archive: <http://sources.redhat.com/ml/gdb/>
List-Post: <mailto:gdb@sources.redhat.com>
List-Help: <mailto:gdb-help@sources.redhat.com>, <http://sources.redhat.com/ml/#faqs>
Sender: gdb-owner@sources.redhat.com
Received: (qmail 7657 invoked from network); 8 Jan 2003 20:46:20 -0000
Received: from unknown (HELO crack.them.org) (65.125.64.184)
  by 209.249.29.67 with SMTP; 8 Jan 2003 20:46:20 -0000
Received: from nevyn.them.org ([66.93.61.169] ident=mail)
	by crack.them.org with asmtp (Exim 3.12 #1 (Debian))
	id 18WOyD-0000Sy-00; Wed, 08 Jan 2003 16:46:46 -0600
Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian))
	id 18WN5o-0001lt-00; Wed, 08 Jan 2003 15:46:28 -0500
Date: Wed, 08 Jan 2003 20:46:00 -0000
From: Daniel Jacobowitz <drow@mvista.com>
To: Sunil Alankar <sunil.alankar@coware.com>
Cc: gdb@sources.redhat.com
Subject: Re: GDB 5.2/5.3 breakpoint bug
Message-ID: <20030108204628.GA6776@nevyn.them.org>
Mail-Followup-To: Sunil Alankar <sunil.alankar@coware.com>,
	gdb@sources.redhat.com
References: <IMEGIEBLGLIOEGOLAFIEGEOPCEAA.sunil.alankar@coware.com> <IMEGIEBLGLIOEGOLAFIEAEPDCEAA.sunil.alankar@coware.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <IMEGIEBLGLIOEGOLAFIEAEPDCEAA.sunil.alankar@coware.com>
User-Agent: Mutt/1.5.1i
X-SW-Source: 2003-01/txt/msg00093.txt.bz2

On Wed, Jan 08, 2003 at 12:37:29PM -0800, Sunil Alankar wrote:
> Meanwhile, a colleague of mine had a different workaround:
> 
> There is one extra record_line call in gdb 5.21 and gdb 5.3 which inserts
> extra line number
> and pc into the linetable of symtab entry.
> 
> gdb/dbxread.c in gdb.5.1.01
>   1919        if (*name == '\000')
>   1920          {
>   1921            /* This N_FUN marks the end of a function.  This closes
> off the
>   1922               current block.  */
>   1923            within_function = 0;
>   1924            new = pop_context ();
> 
> gdb/dbxread.c in gdb 5.2.1
>   2749        if (*name == '\000')
>   2750          {
>   2751            /* This N_FUN marks the end of a function.  This closes
> off the
>   2752               current block.  */
>   2753            record_line (current_subfile, 0, function_start_offset +
> valu);
>   2754            within_function = 0;
>   2755            new = pop_context ();
>   2756
> 
> gdb/dbxread.c in gdb 5.3
> 
>   2773        if (*name == '\000')
>   2774          {
>   2775            /* This N_FUN marks the end of a function.  This closes
> off the
>   2776               current block.  */
>   2777            record_line (current_subfile, 0, function_start_offset +
> valu);
>   2778            within_function = 0;
>   2779            new = pop_context ();
>   2780
> 
> 
> Comment out the line 2753 in gdb 5.21 and 2777 in gdb  5.3 and build them on
> solaris seems to work OK with two test cases.
> 
> Now the  question is to figure out why this line is added in gdb 5.21 and
> gdb 5.3?

The line is supposed to be there; it's so we know what is and isn't
inside a function.  You need to explain better why it's causing a
problem in find_pc_sect_line.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer