Re: GDB 5.2/5.3 breakpoint bug

["Ching Lai" <ching@coware.com>]

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.

db) x/320d &s->linetable.nitems
0x6debf0:       77      1667196020      3069    1667200366
0x6dec00:       0       1229376 3069    1701207922
....
0x6df080:       0       1231068 1224    0
0x6df090:       0       1231080 1226    0
0x6df0a0:       0       1231080 1228    0
0x6df0b0:       0       1231152 0       0
0x6df0c0:       0       1231160 0       0            <=================  pc
1231160 with line number 0 for sc_unsigned.h symbol
0x6df0d0:       0       0       795176551       762405167
0x6df0e0:       1667787118      1731159908      1647129902      841888046
gdb) p pc
$37 = 1231164   <========= pc that we are looking for line number of a
symbol
gdb) p s->filename
$38 = 0x6f54c0
"/eng-qa/ching/sv4.1/source/../release/solaris/tools/include/systemc/datatyp
es/int/sc_unsigned.h"
(gdb) p *s
$39 = {next = 0x6f53b0, blockvector = 0x6f4578, linetable = 0x6debf0,
block_line_section = 10, primary = 0, filename = 0x6f54c0 "/
eng-qa/ching/sv4.1/source/../release/solaris/tools/include/systemc/datatypes
/int/sc_unsigned.h", dirname = 0x6df0d8 "/eng-qa/ching
/gdb-5.2.1.inst/bin/", free_code = free_linetable, free_ptr = 0x0, nlines =
0, line_charpos = 0x0, language = language_cplus, debu
gformat = 0x6f5520 "unknown", version = 0x0, fullname = 0x0, objfile =
0x28ca98}

gdb) x/80d &s->linetable.nitems
0x6f4660:       14      0       8       0
0x6f4670:       0       114628  8       0
....
0x6f46f0:       0       114740  5       0
0x6f4700:       0       1231160 5       0    <=============== another pc
with the correct line number 5 for t.cpp symbol
0x6f4710:       0       1231168 6       0
0x6f4720:       0       1231184 7       0
0x6f4730:       0       1231192 0       0
0x6f4740:       0       1231200 0       0
0x6f4750:       0       0       795176551       762405167
0x6f4760:       1667787118      1731159908      1647129902      841888046
(gdb) p pc
$41 = 1231164

(gdb) p s->filename
$42 = 0x6f4630 "/eng-qa/ching/gdb-5.2.1.inst/bin/t.cpp"


Does this make sense?

Thanks.


Ching

----- Original Message -----
From: "Daniel Jacobowitz" <drow@mvista.com>
To: "Sunil Alankar" <sunil.alankar@CoWare.com>
Cc: <gdb@sources.redhat.com>
Sent: Wednesday, January 08, 2003 12:46 PM
Subject: Re: GDB 5.2/5.3 breakpoint bug


> 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
>