This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: GDB 5.2/5.3 breakpoint bug
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
>