Re: DWARF2 CFI in absence of a frame pointer

[Mark Kettenis <kettenis at chello dot nl>]

   Date: Thu, 27 Nov 2003 15:44:31 -0800
   From: Richard Henderson <rth@redhat.com>

   On Fri, Nov 28, 2003 at 12:08:53AM +0100, Mark Kettenis wrote:
   > In particular, GCC will generate CFI for the epilogue ...

   This should not be happening.  We don't generate CFI for the
   epilogue *at all*.  We should, I know, but we don't.  There
   is an open enhancement PR for this.

   Do you have an example that shows this bug?

I have now :-).  Using the source files at the end of this message I
get:

$ gcc33 -g -O2 -c -fomit-frame-pointer badcfi.c
$ gcc33 -g -o testcfi testcfi.c badcfi.o
$ gdb testcfi
GNU gdb 2003-11-14-cvs
Copyright 2003 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-unknown-freebsd4.7"...
(gdb) b bar
Breakpoint 1 at 0x8048478: file testcfi.c, line 10.
(gdb) r
Starting program: /home/kettenis/tmp/testcfi 

Breakpoint 1, 0x08048478 in bar () at testcfi.c:10
10      {
(gdb) bt
#0  0x08048478 in bar () at testcfi.c:10
#1  0x080484b1 in foobar () at badcfi.c:10
#2  0x00000001 in ?? ()
#3  0xbfbff784 in ?? ()
#4  0xbfbff78c in ?? ()
#5  0x0804848f in main () at testcfi.c:16
(gdb) 

This is on i386-unknown-freebsd4.7 with:

$ gcc33 --version
gcc33 (GCC) 3.3.3 20031103 (prerelease) [FreeBSD]
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

which has been compiled from FreeBSD's package system.  While this
version has a small number of FreeBSD-specific patches, I'm pretty
sure they don't affect the problem I'm seeing.

Anyway, if you look at the output generated by

$ gcc33 -S -dA -g -O2 -fomit-frame-pointer badcfi.c

[snip]

.globl foobar
        .type   foobar, @function
foobar:
.LFB3:
        # badcfi.c:6
        .loc 1 6 0
        # basic block 0
        subl    $12, %esp
.LCFI0:
        # badcfi.c:7
        .loc 1 7 0
        call    foo
        testl   %eax, %eax
        je      .L4
        # badcfi.c:16
        .loc 1 16 0
.L1:
        # basic block 1
        movl    $1, %eax
        addl    $12, %esp
.LCFI1:
        ret
        # badcfi.c:10
        .loc 1 10 0
        .p2align 2,,3
.L4:
        # basic block 2
        call    bar
        # badcfi.c:12
        .loc 1 12 0
        call    foo
        jmp     .L1
.LFE3:
        .size   foobar, .-foobar

[snip]

you'll notice the .LCFI1 label used to generate CFI for the "ret"
instruction.  The same state gets used for "basic block 2" for which
it isn't right.

While this example is for i386-unknown-freebsd4.7, I see similar
behaviour on x86_64-unknownd-freebsd5.1.  Here it isn't necessary to
specify -fomit-frame-pointer, since it's the default.

Should I file a bug report with this analysis?

Mark


--- badcfi.c ---

int foo (void);
void bar (void);

int
foobar (void)
{
  if (foo ())
    return 1;

  bar ();

  if (foo ())
    return 1;

  return 1;
}

--- testcfi.c ---

int foobar (void);

int
foo (void)
{
}

int
bar (void)
{
}

int
main (void)
{
  foobar ();
}