This is the mail archive of the
gdb-prs@sources.redhat.com
mailing list for the GDB project.
symtab/886: source line information sometimes not found when #line directives are used
- From: dgay at intel-research dot net
- To: gdb-gnats at sources dot redhat dot com
- Date: 12 Dec 2002 18:47:05 -0000
- Subject: symtab/886: source line information sometimes not found when #line directives are used
- Reply-to: dgay at intel-research dot net
>Number: 886
>Category: symtab
>Synopsis: source line information sometimes not found when #line directives are used
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: unassigned
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Thu Dec 12 10:48:04 PST 2002
>Closed-Date:
>Last-Modified:
>Originator: dgay@intel-research.net
>Release: 20021204 snapshot
>Organization:
>Environment:
redhat linux 7.2
gcc version:
gcc version 2.96 20000731 (Red Hat Linux 7.2 2.96-112.7.2)
>Description:
When setting a breakpoint at the entrypoint of a function f (i.e., b *f rather than b f), the source code location for f is not found if (the names below are arbitrary):
- f is in file "x.c", but preceded by a #line directive pointing to "f.c"
- the function g immediately preceding f in "x.c" is marked by a #line directive as being in "g.c"
- there are no #line directives for "g.c" after g
- f immediately follows g in the executable (no padding, e.g.)
>How-To-Repeat:
Extract files from the attached tarball, and execute the exhibit script on an i386 machine. The output shows two breakpoints: "b fun2" (works), "b *fun2" (doesn't display source code information)
The same problem definitely shows up with avr-gcc/avr-gdb. I expect it will happen on other machines too.
The source code in test.c follows the pattern described above, exhibit compiles it with no inter-function padding.
>Fix:
The following patch fixes the problem, for me at least... Read the comment for details.
--- gdb+dejagnu-5.2.90_20021204/gdb/symtab.c Thu Aug 29 20:24:00 2002
+++ patched-gdb/gdb/symtab.c Wed Dec 11 18:09:09 2002
@@ -1940,7 +1940,18 @@
/* 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 (prev && (!best || prev->pc > best->pc))
+ /* DG: If a fn f, marked with #line as being in file F is preceded by
+ a fn g, marked with #line as belonging to file G, and g is the
+ last function marked as belonging to G, then the block vector for
+ G contains a symtab with line number 0 and the address of the
+ first byte of f. If G is seen before F, then this symtab entry
+ will win the "best" competition and no location info will be given
+ for (e.g.) breakpoints set at f.
+ Fix: for equal pc, give preference to symtabs with non-zero line
+ numbers. */
+
+ if (prev && (!best || prev->pc > best->pc ||
+ (prev->pc == best->pc && !best->line && prev->line)))
{
best = prev;
best_symtab = s;
>Release-Note:
>Audit-Trail:
>Unformatted: