[RFA/testsuite] Shorten the maint.exp symbols tests

[RFA/testsuite] Shorten the maint.exp symbols tests

[Daniel Jacobowitz]

Right now maint.exp dumps the contents of all symbols.  There's a comment
from Jim that, if the C library has debug info, this can take a long time. 
And we bump the timeout way up.

Well, on my test systems it takes longer than just a long time: it takes
about 45 minutes.  And the generated files are close to a gigabyte.  I think
that's a little bit overkill, don't you? :)

I modified the test to dump just the symbols for the files we're interested
in, and it works quite nicely.  This cuts the test time back to a reasonable
amount.  Is this change OK?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

2002-10-21  Daniel Jacobowitz  <drow@mvista.com>

	* gdb.base/maint.exp: Only dump symbols from one source file
	or objfile.

Index: testsuite/gdb.base/maint.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.base/maint.exp,v
retrieving revision 1.14
diff -u -p -r1.14 maint.exp
--- testsuite/gdb.base/maint.exp	18 Sep 2002 23:53:52 -0000	1.14
+++ testsuite/gdb.base/maint.exp	13 Oct 2002 22:55:02 -0000
@@ -230,9 +230,9 @@ gdb_expect  {
         timeout         { fail "(timeout) maint print psymbols w/o args" }
         }
 
-send_gdb "maint print psymbols psymbols_output\n"
+send_gdb "maint print psymbols psymbols_output ${srcdir}/${subdir}/${srcfile}\n"
 gdb_expect  {
-        -re "^maint print psymbols psymbols_output\r\n$gdb_prompt $"\
+        -re "^maint print psymbols psymbols_output \[^\n\]*\r\n$gdb_prompt $"\
          {
           send_gdb "shell ls psymbols_output\n"
           gdb_expect {
@@ -272,9 +272,9 @@ gdb_expect  {
         timeout         { fail "(timeout) maint print msymbols w/o args" }
         }
 
-send_gdb "maint print msymbols msymbols_output\n"
+send_gdb "maint print msymbols msymbols_output ${binfile}\n"
 gdb_expect  {
-        -re "^maint print msymbols msymbols_output\r\n$gdb_prompt $"\
+        -re "^maint print msymbols msymbols_output \[^\n\]*\r\n$gdb_prompt $"\
          {
           send_gdb "shell ls msymbols_output\n"
           gdb_expect {
@@ -307,16 +307,13 @@ gdb_expect  {
         timeout         { fail "(timeout) maint print symbols w/o args" }
         }
 
-# This command can legitimately take many minutes to execute.  If the
-# executable is dynamically linked, then you get all the debugging
-# info for the entire library --- 89Mb on my system.  -jimb
+# Request symbols for one particular source file so that we don't try to
+# dump the symbol information for the entire C library - over 500MB nowadays
+# for GNU libc.
 
-set old_timeout $timeout
-set timeout 600
-
-send_gdb "maint print symbols symbols_output\n"
+send_gdb "maint print symbols symbols_output ${srcdir}/${subdir}/${srcfile}\n"
 gdb_expect  {
-        -re "^maint print symbols symbols_output\r\n$gdb_prompt $"\
+        -re "^maint print symbols symbols_output \[^\n\]*\r\n$gdb_prompt $"\
          {
           send_gdb "shell ls symbols_output\n"
           gdb_expect {
@@ -340,8 +337,6 @@ gdb_expect  {
         -re ".*$gdb_prompt $"       { fail "maint print symbols" }
         timeout         { fail "(timeout) maint print symbols" }
         }
-
-set timeout $old_timeout
 
 send_gdb "maint print type argc\n"
 gdb_expect  {

Re: [RFA/testsuite] Shorten the maint.exp symbols tests

[Fernando Nasser]

We haven't heard anything against it from the other C++ folks and, IMO, 
we don't have any choice -- we just can't handle all symbols.

Please check it in and thank you for the fix.

Regards,
Fernando

Daniel Jacobowitz wrote:
> Right now maint.exp dumps the contents of all symbols.  There's a comment
> from Jim that, if the C library has debug info, this can take a long time. 
> And we bump the timeout way up.
> 
> Well, on my test systems it takes longer than just a long time: it takes
> about 45 minutes.  And the generated files are close to a gigabyte.  I think
> that's a little bit overkill, don't you? :)
> 
> I modified the test to dump just the symbols for the files we're interested
> in, and it works quite nicely.  This cuts the test time back to a reasonable
> amount.  Is this change OK?
> 


-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Re: [RFA/testsuite] Shorten the maint.exp symbols tests

[David Carlton]

The maint.exp changes in question cause testsuite failures on my
system for 'maint print symbols' and 'maint print psymbols'.  I've
played around with it a bit; it seems to me that if I do

(gdb) maint print symbols symbols_output ./gdb.base/break.c

(which is what maint.exp does in my situation) then I get an empty
file symbols_output, whereas if I just do

(gdb) maint print symbols symbols_output gdb.base/break.c

then I get the correct symbols_output file.  Here, I'm running GDB
from within the testsuite directory; I don't use a separate build
directory when configuring GDB, which might or might not make a
difference.

David Carlton
carlton@math.stanford.edu

Re: [RFA/testsuite] Shorten the maint.exp symbols tests

[Daniel Jacobowitz]

On Wed, Dec 04, 2002 at 01:52:04PM -0800, David Carlton wrote:
> The maint.exp changes in question cause testsuite failures on my
> system for 'maint print symbols' and 'maint print psymbols'.  I've
> played around with it a bit; it seems to me that if I do
> 
> (gdb) maint print symbols symbols_output ./gdb.base/break.c
> 
> (which is what maint.exp does in my situation) then I get an empty
> file symbols_output, whereas if I just do
> 
> (gdb) maint print symbols symbols_output gdb.base/break.c
> 
> then I get the correct symbols_output file.  Here, I'm running GDB
> from within the testsuite directory; I don't use a separate build
> directory when configuring GDB, which might or might not make a
> difference.

Blech!  I'm not sure what to do about this.  Somehow we'd need to
figure out how the file was compiled - is the logic to decide this in
gdb_compile?  Does the compiler clean it up on its own?  Maybe if we
pass an explicit srcdir to gdb_compile we can get consistent results
here.

Or maybe we should make 'maint print symbols symbols_output break.c'
match all files ending in break.c.  That's much less fragile.  What do
you think?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFA/testsuite] Shorten the maint.exp symbols tests

[David Carlton]

On Wed, 4 Dec 2002 17:20:32 -0500, Daniel Jacobowitz <drow@mvista.com> said:
> On Wed, Dec 04, 2002 at 01:52:04PM -0800, David Carlton wrote:

>> The maint.exp changes in question cause testsuite failures on my
>> system for 'maint print symbols' and 'maint print psymbols'.  I've
>> played around with it a bit; it seems to me that if I do
>> 
>> (gdb) maint print symbols symbols_output ./gdb.base/break.c
>> 
>> (which is what maint.exp does in my situation) then I get an empty
>> file symbols_output, whereas if I just do
>> 
>> (gdb) maint print symbols symbols_output gdb.base/break.c
>> 
>> then I get the correct symbols_output file.  Here, I'm running GDB
>> from within the testsuite directory; I don't use a separate build
>> directory when configuring GDB, which might or might not make a
>> difference.

> Blech!  I'm not sure what to do about this.  Somehow we'd need to
> figure out how the file was compiled - is the logic to decide this
> in gdb_compile?  Does the compiler clean it up on its own?  Maybe if
> we pass an explicit srcdir to gdb_compile we can get consistent
> results here.

It's certainly not obvious to me how to fix the testsuite in this
situation.  After all, gdb_compile gets passed
${srcdir}/${subdir}/${srcfile}, which is exactly what you look for in
your maint print symbols call ("./gdb.base/break.c" in my example), so
I have a hard time imagining what a simple fix might be to the
testsuite that would allow it to guess the right thing (barring some
fragile hack like checking if $srcdir is ".").

> Or maybe we should make 'maint print symbols symbols_output break.c'
> match all files ending in break.c.  That's much less fragile.  What
> do you think?

If it's easy to implement, one possibility would be for maint print
symbols to turn its argument into an absolute path (in a fairly
canonical form, so without ".", "..", and possibly without symbol
links) and to do the same thing for the filenames associated to the
symtabs before comparing those filenames to its argument.

David Carlton
carlton@math.stanford.edu

Re: [RFA/testsuite] Shorten the maint.exp symbols tests

[David Carlton]

On 04 Dec 2002 14:47:20 -0800, David Carlton <carlton@math.Stanford.EDU> said:
> On Wed, 4 Dec 2002 17:20:32 -0500, Daniel Jacobowitz <drow@mvista.com> said:

>> Blech!  I'm not sure what to do about this.  Somehow we'd need to
>> figure out how the file was compiled - is the logic to decide this
>> in gdb_compile?  Does the compiler clean it up on its own?  Maybe if
>> we pass an explicit srcdir to gdb_compile we can get consistent
>> results here.

> It's certainly not obvious to me how to fix the testsuite in this
> situation.  After all, gdb_compile gets passed
> ${srcdir}/${subdir}/${srcfile}, which is exactly what you look for in
> your maint print symbols call ("./gdb.base/break.c" in my example), so
> I have a hard time imagining what a simple fix might be to the
> testsuite that would allow it to guess the right thing (barring some
> fragile hack like checking if $srcdir is ".").

I thought of another possible solution: maint.exp could copy
${srcdir}/${subdir}/${srcfile} to the current directory, then just
compile ${srcfile} without any path, and delete the stuff in the
current directory at the end of the tests.  That's still not a great
solution, and I think probably the ultimate solution is to teach maint
print about canonical filenames, but it might work for now.

David Carlton
carlton@math.stanford.edu