Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: "Ching Lai" <ching@coware.com>
To: "Daniel Jacobowitz" <drow@mvista.com>
Cc: "Nafees" <nafees@coware.com>, <gdb@sources.redhat.com>,
	"Cesar Quiroz" <Cesar.Quiroz@coware.com>,
	"Sunil Alankar" <salankar@coware.com>
Subject: Re: GDB 5.2/5.3 breakpoint bug
Date: Thu, 09 Jan 2003 05:18:00 -0000	[thread overview]
Message-ID: <001701c2b79e$787710e0$0200a8c0@shu> (raw)
In-Reply-To: <20030109034002.GC10532@nevyn.them.org>

Hi Daniel,

Thanks for the quick response and the patch.

Yes, the patch should fix the problem.  I made the same change
on my local copy of gdb 5.2.1 and it seems to work OK on my two test cases.

I reported the problem  in 11/25/02 to gdb bug report system with the bug
tracking number 849.

You should be able to close the bug.

Thanks again for your help.

Ching


      Reporter's email: ching@coware.com
      CC these people
      on PR status email:

      Number: 849
      Category: gdb
      Synopsis: no break line when stop at member function of a class
      Confidential: no
      Severity: serious
      Priority: medium
      Responsible: unassigned
      State: open
      Class: sw-bug
      Submitter-Id: net
      Arrival-Date: Mon Nov 25 10:08:03 PST 2002
      Closed-Date:
      Last-Modified:
      Originator: ching@coware.com
      Release: gdb5.2.1
      Organization:
      Environment: solaris 2.7

      Description: There is no break number displayed when you stop at
member function of a class for gdb5.2.1. It only happens in Solaris version
of gdb5.2.1. The linux version works OK. The previous
      version of solaris gdb 5.1 also works OK. So it must be something
change from 5.1  to 5.2.1. It seems to stop at the correctly location, but
just did not display the line number.
      /home/ching/testcase [tesla 6]>/eng-


----- Original Message -----
From: "Daniel Jacobowitz" <drow@mvista.com>
To: "Ching Lai" <ching@CoWare.com>
Cc: "Nafees" <nafees@CoWare.com>; <gdb@sources.redhat.com>; "Cesar Quiroz"
<Cesar.Quiroz@CoWare.com>; "Sunil Alankar" <salankar@CoWare.com>
Sent: Wednesday, January 08, 2003 7:40 PM
Subject: Re: GDB 5.2/5.3 breakpoint bug


> On Wed, Jan 08, 2003 at 02:45:23PM -0800, Ching Lai wrote:
> > Hi Daniel,
> >
> > > > 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.
> >
> > The problem is the linetable in different symbol tables have the
> > same pc address in my testcase. One has valid number and the other one
> > with line number as 0 (which is added by the extra record_line()).
> >
> > In gdb 5.2.1 release of find_pc_set_line in symtab.c file.
> >
> >   1788        /* Is this file's best line closer than the best in the
other
> > files?
> >   1789           If so, record this file, and its best line, as best so
far.
> > */
> >   1790
> >   1791        if (prev && (!best || prev->pc > best->pc))
> >   1792          {
> >   1793            best = prev;
> >   1794            best_symtab = s;
> >   1795
> >   1796            /* Discard BEST_END if it's before the PC of the
current
> > BEST.  */
> >   1797            if (best_end <= best->pc)
> >   1798              best_end = 0;
> >   1799          }
> >
> > Since the line 1791 prev->pc with valid line number is not greater than
> > best->pc
> > which has 0 as line number, so it did not pick up the correct symbol
file.
> >
> > If the record_line is need in gdb 5.2.1 and gdb 5.3, then the line 1791
> > might
> > need an extra condition to void picking up the wrong symbol table which
has
> > line
> > number as 0 as added by record_line().
> >
> > 1791        if (prev && (!best || prev->pc > best->pc) && (prev->line !=
0))
> >
> >
> > Here are the debugging  section of my observation.
>
> Thanks for the extra detail.  I see what's going on now; I believe this
> patch should also avoid the problem.  Does it?
>
> --
> Daniel Jacobowitz
> MontaVista Software                         Debian GNU/Linux Developer
>
> 2002-03-08  Daniel Jacobowitz  <drow@mvista.com>
>
> * symtab.c (find_pc_sect_line): Don't consider end-of-function
> lines.
>
> Index: symtab.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/symtab.c,v
> retrieving revision 1.84
> diff -u -p -r1.84 symtab.c
> --- symtab.c 2 Jan 2003 14:27:26 -0000 1.84
> +++ symtab.c 9 Jan 2003 03:38:36 -0000
> @@ -2012,9 +2012,11 @@ find_pc_sect_line (CORE_ADDR pc, struct
>           the first line, prev will not be set.  */
>
>        /* Is this file's best line closer than the best in the other
files?
> -         If so, record this file, and its best line, as best so far.  */
> +         If so, record this file, and its best line, as best so far.
Don't
> +         save prev if it represents the end of a function (i.e. line
number
> +         0) instead of a real line.  */
>
> -      if (prev && (!best || prev->pc > best->pc))
> +      if (prev && prev->line && (!best || prev->pc > best->pc))
>   {
>     best = prev;
>     best_symtab = s;


  reply	other threads:[~2003-01-09  5:18 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <IMEGIEBLGLIOEGOLAFIEGELNCEAA.sunil.alankar@coware.com>
2003-01-05 23:10 ` Sunil Alankar
2003-01-05 23:14   ` Sunil Alankar
2003-01-07 23:55     ` Sunil Alankar
2003-01-08  0:52       ` Daniel Jacobowitz
2003-01-08 17:39       ` Daniel Jacobowitz
2003-01-08 18:16         ` Daniel Jacobowitz
2003-01-08 19:22           ` Sunil Alankar
2003-01-08 19:32             ` Daniel Jacobowitz
2003-01-08 19:43               ` Sunil Alankar
2003-01-08 20:42                 ` Sunil Alankar
2003-01-08 20:46                   ` Daniel Jacobowitz
2003-01-08 22:46                     ` Ching Lai
2003-01-09  3:40                       ` Daniel Jacobowitz
2003-01-09  5:18                         ` Ching Lai [this message]
2003-01-08 17:30   ` Daniel Jacobowitz
2003-01-08 18:14     ` Sunil Alankar
2003-01-08 18:24       ` Daniel Jacobowitz
2003-01-29  3:56       ` Daniel Jacobowitz
2003-01-02 20:59 how to access show/set data Kris Warkentin
2003-01-04  2:19 ` GDB 5.2/5.3 breakpoint bug Sunil Alankar
2003-01-04  2:23   ` Daniel Jacobowitz

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='001701c2b79e$787710e0$0200a8c0@shu' \
    --to=ching@coware.com \
    --cc=Cesar.Quiroz@coware.com \
    --cc=drow@mvista.com \
    --cc=gdb@sources.redhat.com \
    --cc=nafees@coware.com \
    --cc=salankar@coware.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