expand-symtabs.exp

[Jim Blandy]

> Carlos, Jim, what is this test supposed to check?  It makes absolutely
> no sense to me.

I've committed the patch below, which hopefully provides more detail.

Ideally, the test would actually run GDB twice, setting a breakpoint
in foo the first time and in main the second, to avoid being sensitive
to the order in which GDB sees the partial symtabs.

gdb/testsuite/ChangeLog:
2008-01-27  Jim Blandy  <jimb@codesourcery.com>

	* gdb.base/expand-psymtabs.exp: Doc fix.

diff -r 37542ef56b07 gdb/testsuite/gdb.base/expand-psymtabs.exp
--- a/gdb/testsuite/gdb.base/expand-psymtabs.exp	Sun Jan 27 09:17:01 2008 -0800
+++ b/gdb/testsuite/gdb.base/expand-psymtabs.exp	Sun Jan 27 09:18:18 2008 -0800
@@ -20,7 +20,18 @@ if $tracelevel then {
     strace $tracelevel
 }
 
-# Test expanding partial symtabs when needed.
+# It's possible to have a program that contains two compilation units
+# for the same source file name, that have code at different lines.
+# For example, in this test, we compile expand-psymtabs.c twice with
+# different preprocessor symbols #defined; the first .o only has
+# 'main' at some earlier source lines, while the second .o only has
+# 'foo' at later source lines.  So when setting breakpoints by line
+# number, which full symtab we need dependings on the line number in
+# question.
+#
+# This test is meant to verify that, even with lazy partial symtab
+# reading in effect, GDB can set breakpoints by line number
+# successfully in either compilation unit.  
 
 set testfile expand-psymtabs
 set srcfile ${testfile}.c