Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
* Re: [PATCH] Make tests more flexible
@ 2003-01-16  4:36 Michael Elizabeth Chastain
  0 siblings, 0 replies; 14+ messages in thread
From: Michael Elizabeth Chastain @ 2003-01-16  4:36 UTC (permalink / raw)
  To: ezannoni, gdb-patches; +Cc: carlton

Aiieee, that explains why my test bed blew up!

  cvs checkout gdb HEAD:
    date_start="2003-01-15T01:24:53Z"
    date_finish="2003-01-15T01:27:55Z"

I'll re-checkout the gdb's, re-build, and re-test (the binutil's and
gcc's will still be from yesterday, it takes me 17 hours to build all
the CVS compilers+binutils that I test).

In about 13 hours I'll know if there are any residual problems in
my configurations, and I'll report them in my usual nit-picky way.  :)

Michael C


^ permalink raw reply	[flat|nested] 14+ messages in thread
* Re: [PATCH] Make tests more flexible
@ 2003-01-16 18:45 Michael Elizabeth Chastain
  0 siblings, 0 replies; 14+ messages in thread
From: Michael Elizabeth Chastain @ 2003-01-16 18:45 UTC (permalink / raw)
  To: ezannoni; +Cc: carlton, gdb-patches

Elena Z asks:
> So, recapping, which one is correct? the old compiler (and the test is
> right) or the new compiler (and the test is wrong)?

Argh, my previous answer was crap.  But now I understand.
It will be easy to fix, too.

Here is the source code for advance.c:
     
  int
  main ()
  {
    int result;
    int b, c;
    c = 5;
    b = 3;    /* advance this location */

    func (c); /* stop here after leaving current frame */
    func3 (); /* break here */
    result = bar (b + foo (c));
    return 0; /* advance malformed */
  }

Here is some generated assembly code with gcc 2.95.3:

  0x8048462 <main+26>:    push   %eax
  0x8048463 <main+27>:    call   0x8048408 <func>
  0x8048468 <main+32>:    add    $0x10,%esp
  0x804846b <main+35>:    call   0x8048434 <func3>

Here is some generated assembly code with gcc 3.2.1:

  0x80483d3 <main+33>:    mov    %eax,(%esp,1)
  0x80483d6 <main+36>:    call   0x8048380 <func>
  0x80483db <main+41>:    call   0x80483a3 <func3>

After the call to 'func', gcc v2 emits an instruction to clean up
the arguments on the stack ('add $0x10,%esp').  gcc v3 does lazy
stack cleanup, it lets stuff stay on the stack for a while and
cleans it up later, saving some instructions.

Here is a log excerpt with gcc 2.95.3:

  # target=native, host=i686-pc-linux-gnu, osversion=red-hat-8.0,
  # gdb=HEAD%20030115, gcc=2.95.3, binutils=2.13.2.1, libc=vendor,
  # gformat=dwarf-2

  advance func3^M
  0x08048468 in main () at /berman/fsf/_today_/source/gdb/HEAD/src/gdb/testsuite/gdb.base/advance.c:40^M
  40        func (c); /* stop here after leaving current frame
  */^M
  (gdb) PASS: gdb.base/advance.exp: advance function not called by current frame

gdb hits the return breakpoint, which is on the 'add $0x10,%esp'
instruction, still in the middle of line 40.

And here is a log excerpt from gcc 3.2.1:

  # target=native, host=i686-pc-linux-gnu, osversion=red-hat-8.0,
  # gdb=HEAD%20030115, gcc=3.2.1, binutils=2.13.2.1, libc=vendor,
  # gformat=dwarf-2

  advance func3^M
  main () at /berman/fsf/_today_/source/gdb/HEAD/src/gdb/testsuite/gdb.base/advance.c:41^M
  41        func3 (); /* break here */^M
  (gdb) FAIL: gdb.base/advance.exp: advance function not called by current frame

gdb hits the return breakpoint, which is the first instruction of line 41.

So gdb is doing the right thing, but the test script is too strict.
gdb might stop on either line 40 or line 41, depending on how the
function call in line 40 gets compiled: whether the 'call' instruction
is the last machine instruction for line 40 or not.

In general we can't say anything about whether the 'call' instruction
will be the last machine instruction for a C function call, so we
can't predict whether the return breakpoint will be an instruction
in line 40 or the first instruction of line 41.  The test script has
to acommodate both forms.

Michael C


^ permalink raw reply	[flat|nested] 14+ messages in thread
* Re: [PATCH] Make tests more flexible
@ 2003-01-16 18:07 Michael Elizabeth Chastain
  0 siblings, 0 replies; 14+ messages in thread
From: Michael Elizabeth Chastain @ 2003-01-16 18:07 UTC (permalink / raw)
  To: ezannoni; +Cc: carlton, gdb-patches

I read the tests and I think that the tests are written correctly.
So I think that either gcc is wrong, or gdb is wrong.

Michael C


^ permalink raw reply	[flat|nested] 14+ messages in thread
* Re: [PATCH] Make tests more flexible
@ 2003-01-16 17:35 Michael Elizabeth Chastain
  2003-01-16 17:53 ` Elena Zannoni
  0 siblings, 1 reply; 14+ messages in thread
From: Michael Elizabeth Chastain @ 2003-01-16 17:35 UTC (permalink / raw)
  To: carlton, ezannoni; +Cc: gdb-patches

Ah, okay, my head is spinning with all the mail flying around.

David C's log files are the same as my log files.
It looks like one bug in both advance.exp and until.exp.
For me:
  It happened the same way for both dwarf-2 and stabs+.
  It happened the same way with all binutils.
  It happened with gcc => 3.2.1, gcc-3_2-branch, gcc-3_3-branch, HEAD.
  It did NOT happen with gcc => 2.95.3, vendor.

So I think there is only one bug here I think Elena Z can reproduce it
by using a gcc v3 compiler with any debug format.

Michael C


^ permalink raw reply	[flat|nested] 14+ messages in thread
* Re: [PATCH] Make tests more flexible
@ 2003-01-16 17:27 Michael Elizabeth Chastain
  0 siblings, 0 replies; 14+ messages in thread
From: Michael Elizabeth Chastain @ 2003-01-16 17:27 UTC (permalink / raw)
  To: ezannoni, gdb-patches, mec; +Cc: carlton

Hi Elena,

My testbed is happy now, there are no residual problems after your
fixes last night.

There is a new bug with 'advance/until', in the case where the user
'advances' or 'untils' to a function that is not called from the
current frame.  With gcc 3.*, gdb runs all the way to the specified
function, and does not hit the breakpoint on the return location
in the caller.  I'll file a bug report shortly with gory details.
David C can probably see it right now with gcc 3.1.

Michael C


^ permalink raw reply	[flat|nested] 14+ messages in thread
* Re: [PATCH] Make tests more flexible
@ 2003-01-16 17:24 Michael Elizabeth Chastain
  0 siblings, 0 replies; 14+ messages in thread
From: Michael Elizabeth Chastain @ 2003-01-16 17:24 UTC (permalink / raw)
  To: ezannoni, fnasser; +Cc: carlton, gdb-patches

For what it's worth, I think my testbed is agnostic about this issue.
So whatever works for David C is okay by me.

When I test, I do something like this (but in Perl not sh):

  # make a new temporary directory
  rm -rf test
  mkdir test
  cd test

  # copy the pristine build directory
  cp -a $dir_gdb_build/testsuite/* .

  # run the tests
  runtest --objdir ... --outdir ... --srcdir ...

Michael C


^ permalink raw reply	[flat|nested] 14+ messages in thread
* [PATCH] Make tests more flexible
@ 2003-01-16  2:05 Elena Zannoni
  2003-01-16  4:50 ` David Carlton
  2003-01-16 14:40 ` Fernando Nasser
  0 siblings, 2 replies; 14+ messages in thread
From: Elena Zannoni @ 2003-01-16  2:05 UTC (permalink / raw)
  To: gdb-patches; +Cc: carlton


David, try this, if it works for you I'll check it in as obvious.

Elena


2003-01-15  Elena Zannoni  <ezannoni@redhat.com>

	* gdb.base/until.exp: Set variable 'srcfile' differently, to allow
	for different test tree configurations.
	Update some tescases accordingly.
	* gdb.base/advance.exp: Ditto.

Index: advance.exp
===================================================================
RCS file: /cvs/uberbaum/gdb/testsuite/gdb.base/advance.exp,v
retrieving revision 1.1
diff -u -p -r1.1 advance.exp
--- advance.exp	15 Jan 2003 14:25:11 -0000	1.1
+++ advance.exp	16 Jan 2003 02:02:23 -0000
@@ -24,11 +24,11 @@ if $tracelevel then {
 }
 
 set testfile advance
-set srcfile ${srcdir}/${subdir}/${testfile}.c
+set srcfile ${testfile}.c
 set binfile ${objdir}/${subdir}/${testfile}
 
 remote_exec build "rm -f ${binfile}"
-if { [gdb_compile "${srcfile}" "${binfile}" executable {debug}] != "" } {
+if { [gdb_compile "${srcdir}/${subdir}/${srcfile}" "${binfile}" executable {debug}] != "" } {
     gdb_suppress_entire_file "Testcase compile failed, so all tests in this file will automatically fail."
 }
 

Index: until.exp
===================================================================
RCS file: /cvs/uberbaum/gdb/testsuite/gdb.base/until.exp,v
retrieving revision 1.1
diff -u -p -r1.1 until.exp
--- until.exp	15 Jan 2003 14:25:10 -0000	1.1
+++ until.exp	16 Jan 2003 02:04:54 -0000
@@ -24,11 +24,11 @@ if $tracelevel then {
 }
 
 set testfile break
-set srcfile ${srcdir}/${subdir}/${testfile}.c
+set srcfile ${testfile}.c
 set binfile ${objdir}/${subdir}/${testfile}
 
 remote_exec build "rm -f ${binfile}"
-if { [gdb_compile "${srcfile}" "${binfile}" executable {debug}] != "" } {
+if { [gdb_compile "${srcdir}/${subdir}/${srcfile}" "${binfile}" executable {debug}] != "" } {
     gdb_suppress_entire_file "Testcase compile failed, so all tests in this file will automatically fail."
 }
 
@@ -63,7 +63,7 @@ delete_breakpoints
 # frame.
 #
 gdb_test "until 99" \
-	"factorial.*value=720.*at ${srcfile}:99.*return \\(value\\)." \
+	"factorial.*value=720.*at.*${srcfile}:99.*return \\(value\\)." \
 	"until factorial, recursive function"
 
 # Run to a function called by main
@@ -76,6 +76,6 @@ delete_breakpoints
 # stop at main, the caller, where we put the 'guard' breakpoint.
 #
 gdb_test "until marker3" \
-	"$hex in main.*argc.*argv.*envp.*at ${srcfile}:82.*marker2 \\(43\\)." \
+	"$hex in main.*argc.*argv.*envp.*at.*${srcfile}:82.*marker2 \\(43\\)." \
 	"until func, not called by current frame"


^ permalink raw reply	[flat|nested] 14+ messages in thread
end of thread, other threads:[~2003-01-16 18:45 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-01-16  4:36 [PATCH] Make tests more flexible Michael Elizabeth Chastain
  -- strict thread matches above, loose matches on Subject: below --
2003-01-16 18:45 Michael Elizabeth Chastain
2003-01-16 18:07 Michael Elizabeth Chastain
2003-01-16 17:35 Michael Elizabeth Chastain
2003-01-16 17:53 ` Elena Zannoni
2003-01-16 17:27 Michael Elizabeth Chastain
2003-01-16 17:24 Michael Elizabeth Chastain
2003-01-16  2:05 Elena Zannoni
2003-01-16  4:50 ` David Carlton
2003-01-16 17:19   ` Elena Zannoni
2003-01-16 14:40 ` Fernando Nasser
2003-01-16 16:40   ` Elena Zannoni
2003-01-16 17:10   ` David Carlton
2003-01-16 17:27     ` Elena Zannoni

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox