This is the mail archive of the gdb-patches@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]

Re: [PATCH] Make tests more flexible


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


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