This is the mail archive of the gdb-prs@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

symtab/886: source line information sometimes not found when #line directives are used


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]