gcc version 3.4 20030929 (experimental). Compile hello.c without and with -pg. -pg adds two bundles to the start of main but the unwind data for main is not changed. objdump and readelf -u without -pg <main>: 00 08 15 08 80 05 [MII] alloc r33=ar.pfs,5,4,0 20 02 30 00 42 60 mov r34=r12 04 08 00 84 mov r35=r1 01 00 00 00 01 00 [MII] nop.m 0x0 00 02 00 62 00 80 mov r32=b0 84 0c 00 90 addl r36=72,r1;; 1c 20 01 48 18 10 [MFB] ld8 r36=[r36] 00 00 00 02 00 00 nop.f 0x0 08 fe ff 58 br.call.sptk.many b0=4000000000000440 <_init+0x150> 02 08 00 46 00 21 [MII] mov r1=r35 e0 00 00 00 42 00 mov r14=r0;; 01 70 00 84 mov r8=r14 00 00 00 00 01 00 [MII] nop.m 0x0 00 08 01 55 00 00 mov.i ar.pfs=r33 00 0a 00 07 mov b0=r32 1d 60 00 44 00 21 [MFB] mov r12=r34 00 00 00 02 00 80 nop.f 0x0 08 00 84 00 br.ret.sptk.many b0;; <main>: [0x4000000000000620-0x4000000000000680), info at +0x828 v1, flags=0x0 ( ), len=16 bytes R2:prologue_gr(mask=[rp,ar.pfs,psp],grsave=r32,rlen=5) P7:pfs_when(t=0) P7:mem_stack_v(t=1) P7:rp_when(t=4) R1:body(rlen=13) B2:epilogue(t=2,ecount=0) R1:prologue(rlen=0) R1:prologue(rlen=0) R1:prologue(rlen=0) R1:prologue(rlen=0) objdump and readelf -u with -pg 02 40 31 10 80 05 [MII] alloc r40=ar.pfs,12,8,0 b0 42 07 00 48 20 addl r43=104,r1;; 05 08 00 84 mov r41=r1 11 00 00 00 01 00 [MIB] nop.m 0x0 a0 02 00 62 00 00 mov r42=b0 38 fd ff 58 br.call.sptk.many b0=40000000000005a0 <_init+0x1a0>;; 00 08 15 08 80 05 [MII] alloc r33=ar.pfs,5,4,0 20 02 30 00 42 60 mov r34=r12 04 08 00 84 mov r35=r1 01 00 00 00 01 00 [MII] nop.m 0x0 00 02 00 62 00 80 mov r32=b0 04 0f 00 90 addl r36=112,r1;; 1c 20 01 48 18 10 [MFB] ld8 r36=[r36] 00 00 00 02 00 00 nop.f 0x0 e8 fc ff 58 br.call.sptk.many b0=4000000000000580 <_init+0x180> 02 08 00 46 00 21 [MII] mov r1=r35 e0 00 00 00 42 00 mov r14=r0;; 01 70 00 84 mov r8=r14 00 00 00 00 01 00 [MII] nop.m 0x0 00 08 01 55 00 00 mov.i ar.pfs=r33 00 0a 00 07 mov b0=r32 1d 60 00 44 00 21 [MFB] mov r12=r34 00 00 00 02 00 80 nop.f 0x0 08 00 84 00 br.ret.sptk.many b0;; <main>: [0x4000000000000860-0x40000000000008e0), info at +0xb30 v1, flags=0x0 ( ), len=16 bytes R2:prologue_gr(mask=[rp,ar.pfs,psp],grsave=r32,rlen=5) P7:pfs_when(t=0) P7:mem_stack_v(t=1) P7:rp_when(t=4) R1:body(rlen=13) B2:epilogue(t=2,ecount=0) R1:prologue(rlen=0) R1:prologue(rlen=0) R1:prologue(rlen=0) R1:prologue(rlen=0) Despite the fact that -pg added two bundles to the start of main which changes the state or ar.pfs and b0, this is not reflected in the unwind data. Backtrace from mcount() or an interrupt while executing the -pg prologue will terminate early. -pg cannot be used with profiling tools that rely on interrupts. The body length in the -pg case does not take account of the two extra bundles. Any error in the last two bundles of the modified body will appear to be outside the body of the procedure and will use the default unwind data for leaf functions. Any error in the last two bundles will get an incorrect backtrace. My best guess at what the unwind data should look like for the second case, it may be possible to shrink this a bit. Untested. <main>: [0x4000000000000860-0x40000000000008e0), info at +0xb30 v1, flags=0x0 ( ), len=?? bytes R1:prologue(rlen=6) P3:pfs_gr(reg=r40) P7:pfs_when(t=0) P3:rp_gr(reg=r42) P7:rp_when(t=5) R1:body(rlen=0) B2:epilogue(t=0,ecount=0) R2:prologue_gr(mask=[rp,ar.pfs,psp],grsave=r32,rlen=5) P7:pfs_when(t=0) P7:mem_stack_v(t=1) P7:rp_when(t=4) R1:body(rlen=13) B2:epilogue(t=2,ecount=0)
Can you attach this hello.c and maybe the preprocessed source file also?
Created attachment 4863 [details] hello.c hello.c, the good old hello world program.
Created attachment 4864 [details] hello.i Pre-processor output
Created attachment 4865 [details] asm output without -pg Assembler code for hello.c
Comment on attachment 4865 [details] asm output without -pg This is the .s output without -pg
Created attachment 4867 [details] asm output with -pg
The problem is with the FUNCTION_PROFILER macro. IA-64 should be using something like PROFILE_HOOK, which emits rtl that the unwind-info generator can see, rather than emitting assembly text directly.
Fixed here: http://gcc.gnu.org/ml/gcc-patches/2005-06/msg00809.html