[Linux-ia64] Re: gas generates incorrect ia64 unwind rlen values

[Linux-ia64] Re: gas generates incorrect ia64 unwind rlen values

[Keith Owens]

Another gas bug with ia64 unwind data in binutils-2.11.90.0.8-12.

arch/ia64/lib/memset.S generates unwind data of

<memset>: [0xe0020000005e07c0-0xe0020000005e0be0), info at +0x6aa5e8
  v1, flags=0x0 ( ), len=8 bytes
    R1:prologue(rlen=1)
    R3:body(rlen\x194)
        B3:epilogue(t=1,ecount890)

An epilogue count of 3890?  I think not.  But wait, it gets worse!  The
raw info data is

e0020000006aa5e8 01000000 00000100 0161c201 ea01b29e

0100      version 1
0000      no flags
01000000  ulen=1 (8 bytes), followed by 8 bytes 0161c201 ea01b29e

01        Prologue R1, rlen=1
61c201    Body R3, rlen\x194
ea        According to IA-64 Software Conventions and Runtime
          Architecture Guide August 2000 (24535802.pdf), Appendix B, ea
          is not a valid code, B3 records should be e0!  Why is gas
          generating ea?
01        t=1
b29e      uleb128 number with x80 set in both bytes!  We have reached
          the end of the data area (ulen=1) but uleb128 says there is
          more data to come.

Sorry for the surfeit of exclamation marks but the ia64 unwind code is
driving me up the wall.  I want kdb to backtrace correctly, all this
garbage data just gets in the way.

[Linux-ia64] Re: gas generates incorrect ia64 unwind rlen values

[Keith Owens]

On 16 Dec 2002 16:25:15 -0500, 
Jim Wilson <wilson@redhat.com> wrote:
>>RH 7.2-ia64, Dec 15 2001.
>
>The tools for this release were based on Summer 2000 FSF sources with patches.
>So they are about 2.5 years old now.

I know, but AFAICT it is the latest that is available on the RH site
for ia64.  If there is a more recent binutils ia64.rpm, point me at it
and I will try it.

>Are you sure this is an assembler problem?  If the compiler is emitting bad
>unwind directives, then it could be a compiler problem.  You didn't mention
>anything about looking at assembly code.

See my follow up mail about memset.S, that is pure assembler.  But just
to be sure, here is traps.c::ia64_fault assembler output.  No spurious
unwind directives from gcc but unwind is still wrong.

.text
	.align 16
	.align 32
	.global ia64_fault#
	.proc ia64_fault#
ia64_fault:
	.prologue 12, 37
	.save ar.pfs, r38
	alloc r38 = ar.pfs, 4, 3, 5, 0
	.fframe 256
	adds r12 = -256, r12
	movl r14 = 34359738383
	.save rp, r37
	mov r37 = b0
	;;
	.body
	and r14 = r14, r33
	movl r15 = 34359738372
[454 lines omitted for brevity]
.L2933:
	mov r39 = r36
	mov r40 = r33
	br.call.sptk.many b0 = ia32_intercept#
	;;
	cmp4.ne p6, p7 = 0, r8
	(p7) br.cond.dpnt .L2880
	addl r39 = @ltoff(.LC39), gp
	;;
	ld8 r39 = [r39]
	br.call.sptk.many b0 = printk#
	;;
	adds r14 = 8, r36
	addl r39 = @ltoff(.LC40), gp
	mov r41 = r34
	;;
	ld8 r40 = [r14]
	ld8 r39 = [r39]
	mov r42 = r33
	mov r43 = r35
	br.call.sptk.many b0 = printk#
[unwind tables in the object say that the body ends here]
	;;
	addl r39 = 11, r0
	mov r40 = r13
	br.call.sptk.many b0 = force_sig#
	;;
	br .L2880
.L2935:
	adds r34 = 144, r12
	addl r40 = @ltoff(.LC41), gp
	shr.u r41 = r33, 16
	;;
	mov r39 = r34
	ld8 r40 = [r40]
	br.call.sptk.many b0 = sprintf#
	;;
	br .L2882
.L2936:
	adds r34 = 144, r12
	addl r40 = @ltoff(.LC42), gp
	mov r41 = r32
	;;
	mov r39 = r34
	ld8 r40 = [r40]
	br.call.sptk.many b0 = sprintf#
	;;
.L2882:
	mov r39 = r34
	mov r40 = r36
	mov r41 = r33
	br.call.sptk.many b0 = die_if_kernel#
	;;
	addl r39 = 4, r0
	mov r40 = r13
	br.call.sptk.many b0 = force_sig#
	;;
.L2880:
	mov ar.pfs = r38
	mov b0 = r37
	.restore sp
	adds r12 = 256, r12
	br.ret.sptk.many b0
	.endp ia64_fault#

Re: [Linux-ia64] Re: gas generates incorrect ia64 unwind rlen values

[David Mosberger]

>>>>> On Mon, 16 Dec 2002 20:00:23 +1100, Keith Owens <kaos@sgi.com> said:

  Keith> Sorry for the surfeit of exclamation marks but the ia64 unwind code is
  Keith> driving me up the wall.  I want kdb to backtrace correctly, all this
  Keith> garbage data just gets in the way.

Then use gcc-3.2 (or backport the fixes).

	--david

Re: [Linux-ia64] Re: gas generates incorrect ia64 unwind rlen values

[David Mosberger]

>>>>> On Tue, 17 Dec 2002 09:12:25 +1100, Keith Owens <kaos@sgi.com> said:

  Keith> On 16 Dec 2002 16:25:15 -0500,
  Keith> Jim Wilson <wilson@redhat.com> wrote:
  >>> RH 7.2-ia64, Dec 15 2001.

  >> The tools for this release were based on Summer 2000 FSF sources
  >> with patches.  So they are about 2.5 years old now.

  Keith> I know, but AFAICT it is the latest that is available on the RH site
  Keith> for ia64.  If there is a more recent binutils ia64.rpm, point me at it
  Keith> and I will try it.

Not Red Hat, but while Debian (unfortunately) still defaults to
gcc-2.9x at the moment, you can do "apt-get install gcc-3.2" to get
something reasonably modern.

	--david

[Linux-ia64] Re: gas generates incorrect ia64 unwind rlen values

[Jim Wilson]

>I know, but AFAICT it is the latest that is available on the RH site
>for ia64.  If there is a more recent binutils ia64.rpm, point me at it
>and I will try it.

Yes, this is the latest one that we give away free of charge to non-customers.
I think we stopped maintaining these tools a while ago when we started
recommending RH AS 2.[01] instead of RHL 7.[012] for IA-64 customers.

If you want to try something newer, the FSF binutils sources are easily
accessible at
        http://sources.redhat.com/binutils

>See my follow up mail about memset.S, that is pure assembler.

Right, I didn't look closely enough at the file name.  There is unfortunately
no testcase though.  I'll have to grab a copy of the kernel sources in order
to get a testcase.

>[454 lines omitted for brevity]

And this isn't usable as a testcase either.

Jim

[Linux-ia64] Re: gas generates incorrect ia64 unwind rlen values

[Keith Owens]

On 16 Dec 2002 18:10:21 -0500, 
Jim Wilson <wilson@redhat.com> wrote:
>Yes, this is the latest one that we give away free of charge to non-customers.
>I think we stopped maintaining these tools a while ago when we started
>recommending RH AS 2.[01] instead of RHL 7.[012] for IA-64 customers.

I built binutils-2.13.90.0.2-2 (from rh 8.0) on ia64.  I extracted the
generated assembler for ia64_fault as traps.S.  The bug still exists in
2.13.90.0.2.  traps.S has been sent to Jim Wilson as a test case.

/usr/src/redhat/BUILD/binutils-2.13.90.0.2/binutils/tmpdir/gas/as -x -mconstant-gp traps.S -o traps.o
/usr/src/redhat/BUILD/binutils-2.13.90.0.2/binutils/readelf -u traps.o

Unwind section '.IA_64.unwind' at offset 0xb40 contains 1 entries:

<ia64_fault>: [0x0-0xad0), info at +0x0
  v1, flags=0x0 ( ), len\x16 bytes
    R2:prologue_gr(mask=[rp,ar.pfs],grsave=r37,rlen=8)
        P7:pfs_when(t=0)
        P7:mem_stack_f(t=2,size%6)
        P7:rp_when(t=7)
    R3:body(rlenG5)			<= should be 511
        B2:epilogue(t=2,ecount=0)
    R1:prologue(rlen=0)

0000000000000000 <ia64_fault>:
   0:   0c 30 31 0e 80 05       [MFI]       alloc r38=ar.pfs,12,7,0
   6:   00 00 00 02 00 80                   nop.f 0x0
   c:   01 60 f8 8c                         adds r12=-256,r12
  10:   04 00 00 00 01 00       [MLX]       nop.m 0x0
  16:   00 08 00 00 00 c0                   movl r14=0x80000000f
  1c:   f1 00 00 60 
  20:   02 00 00 00 01 00       [MII]       nop.m 0x0
  26:   50 02 00 62 00 c0                   mov r37°;;
  2c:   e1 08 31 80                         and r14=r14,r33
.....
 ab0:   00 00 00 00 01 00       [MII]       nop.m 0x0
 ab6:   00 30 01 55 00 00                   mov.i ar.pfs=r38
 abc:   50 0a 00 07                         mov b0=r37
 ac0:   1d 60 00 18 02 21       [MFB]       adds r12%6,r12
 ac6:   00 00 00 02 00 80                   nop.f 0x0
 acc:   08 00 84 00                         br.ret.sptk.many b0;;
 ad0:   0c 00 00 00 01 00       [MFI]       nop.m 0x0			<== end of code at slot 519
 ad6:   00 00 00 02 00 00                   nop.f 0x0
 adc:   00 00 04 00                         nop.i 0x0

Re: [Linux-ia64] Re: gas generates incorrect ia64 unwind rlen values

[David Mosberger]

>>>>> On Tue, 17 Dec 2002 13:34:03 +1100, Keith Owens <kaos@sgi.com> said:

  Keith> I built binutils-2.13.90.0.2-2 (from rh 8.0) on ia64.  I
  Keith> extracted the generated assembler for ia64_fault as traps.S.
  Keith> The bug still exists in 2.13.90.0.2.  traps.S has been sent
  Keith> to Jim Wilson as a test case.

Which compiler did you use?  With gcc-3.0, I get the info attached
below.  It looks correct to me (I only checked the total length, not
the individual regions).

	--david

<ia64_fault>: [0xe00000000442cd00-0xe00000000442d840], info at +0x545c80
  v1, flags=0x0 (), len$ bytes
    R2:prologue_gr(mask=[rp,ar.pfs],grsave=r37,rlen\x14)
        P7:pfs_when(t=0)
        P7:mem_stack_f(t=1,size%6)
        P7:rp_when(t\x13)
    R3:body(rlenU)
        B1:label_state(label=1)
        B2:epilogue(t=2,ecount=0)
    R3:body(rlenG1)
        B1:copy_state(label=1)

e00000000442cd00 <ia64_fault>:
e00000000442cd00:       00 30 31 0e 80 05       [MII]       alloc r38=ar.pfs,12,
7,0
e00000000442cd06:       c0 00 30 7c 46 00                   adds r12=-256,r12
e00000000442cd0c:       00 00 04 00                         nop.i 0x0
      :
e00000000442d820:       00 70 c0 03 96 26       [MII]       addl r14=-2077840,r1
e00000000442d826:       90 02 85 5e 29 60                   shr.u r41=r33,16
e00000000442d82c:       04 61 04 84                         adds r35\x144,r12
e00000000442d830:       1d 00 00 00 01 00       [MFB]       nop.m 0x0
e00000000442d836:       00 00 00 02 00 00                   nop.f 0x0
e00000000442d83c:       c0 fe ff 48                         br.few e000000004426f0 <ia64_fault+0x9f0>;;

Re: [Linux-ia64] Re: gas generates incorrect ia64 unwind rlen values

[David Mosberger]

  David> Which compiler did you use?  With gcc-3.0, I get the info
  David> attached below.  It looks correct to me (I only checked the
  David> total length, not the individual regions).

Typo-alert: make that gcc-3.1 (not gcc-3.0).

	--david

Re: [Linux-ia64] Re: gas generates incorrect ia64 unwind rlen values

[Keith Owens]

On Mon, 16 Dec 2002 18:51:53 -0800, 
David Mosberger <davidm@napali.hpl.hp.com> wrote:
>>>>>> On Tue, 17 Dec 2002 13:34:03 +1100, Keith Owens <kaos@sgi.com> said:
>
>  Keith> I built binutils-2.13.90.0.2-2 (from rh 8.0) on ia64.  I
>  Keith> extracted the generated assembler for ia64_fault as traps.S.
>  Keith> The bug still exists in 2.13.90.0.2.  traps.S has been sent
>  Keith> to Jim Wilson as a test case.
>
>Which compiler did you use?

I used gcc 2.96 20000731 (Red Hat Linux 7.1 2.96-101) to convert
traps.c to traps.S, then extracted the headers and ia64_fault for
testing against gas.  traps.S only has one body.  I wanted to avoid
dumping 530+ lines to the list but ...

Interesting that a different gcc which generates two bodies gets valid
unwind data, but this code with only one body generates invalid unwind
data.  David, what does your unwind data look like after assembling
this code?

	.file	"traps.c"
	.pred.safe_across_calls p1-p5,p16-p63
.text
	.align 16
	.align 32
	.global ia64_fault#
	.proc ia64_fault#
ia64_fault:
	.prologue 12, 37
	.save ar.pfs, r38
	alloc r38 = ar.pfs, 4, 3, 5, 0
	.fframe 256
	adds r12 = -256, r12
	movl r14 = 34359738383
	.save rp, r37
	mov r37 = b0
	;;
	.body
	and r14 = r14, r33
	movl r15 = 34359738372
	;;
	cmp.ne p6, p7 = r15, r14
	adds r14 = 272, r12
	;;
	(p7) movl r15 = 8796093022208
	mov r36 = r14
	(p7) ld8 r14 = [r14]
	;;
	(p7) or r14 = r15, r14
	(p7) mov r15 = r36
	;;
	(p7) st8 [r15] = r14
	(p7) br.cond.dpnt .L2880
	adds r15 = -24, r32
	;;
	cmp.ltu p6, p7 = 23, r15
	(p6) br.cond.dptk .L2936
	addl r14 = @ltoff(.L2937), gp
	;;
	ld8 r14 = [r14]
	;;
	shladd r16 = r15, 3, r14
	;;
	ld8 r15 = [r16]
	;;
	add r15 = r15, r14
	;;
	mov b6 = r15
	br b6
	.align 8
.L2937:
	data8 .L2883-.L2937
	data8 .L2889-.L2937
	data8 .L2903-.L2937
	data8 .L2936-.L2937
	data8 .L2936-.L2937
	data8 .L2915-.L2937
	data8 .L2936-.L2937
	data8 .L2911-.L2937
	data8 .L2926-.L2937
	data8 .L2926-.L2937
	data8 .L2929-.L2937
	data8 .L2915-.L2937
	data8 .L2915-.L2937
	data8 .L2936-.L2937
	data8 .L2936-.L2937
	data8 .L2936-.L2937
	data8 .L2936-.L2937
	data8 .L2936-.L2937
	data8 .L2936-.L2937
	data8 .L2936-.L2937
	data8 .L2936-.L2937
	data8 .L2931-.L2937
	data8 .L2933-.L2937
	data8 .L2935-.L2937
	.align 16
.L2883:
	extr.u r35 = r33, 4, 4
	addl r14 = @ltoff(reason.3#), gp
	adds r34 = 144, r12
	;;
	cmp.ne p6, p7 = 3, r35
	ld8 r14 = [r14]
	mov r39 = r34
	;;
	shladd r14 = r35, 3, r14
	(p6) addl r42 = @ltoff(.LC31), gp
	;;
	ld8 r41 = [r14]
	(p6) ld8 r42 = [r42]
	(p6) br.cond.dptk .L2885
	tbit.z p6, p7 = r33, 37
	;;
	(p7) addl r42 = @ltoff(.LC29), gp
	;;
	(p7) ld8 r42 = [r42]
	(p6) addl r42 = @ltoff(.LC30), gp
	;;
	(p6) ld8 r42 = [r42]
.L2885:
	addl r40 = @ltoff(.LC28), gp
	;;
	ld8 r40 = [r40]
	br.call.sptk.many b0 = sprintf#
	;;
	cmp.ne p6, p7 = 8, r35
	(p6) br.cond.dptk .L2882
	adds r15 = 64, r36
	adds r14 = 8, r36
	addl r39 = @ltoff(.LC32), gp
	;;
	ld8 r40 = [r14]
	ld8 r41 = [r15]
	ld8 r39 = [r39]
	br.call.sptk.many b0 = printk#
	;;
	br .L2880
.L2889:
	tbit.z p6, p7 = r33, 1
	(p6) br.cond.dpnt .L2890
	ld8 r14 = [r36]
	addl r15 = -524289, r0
	;;
	and r14 = r15, r14
	;;
	st8 [r36] = r14
#APP
	mov ar.k5=r13
#NO_APP
	adds r14 = 1496, r13
	;;
	ld4 r15 = [r14]
	;;
	tbit.z p6, p7 = r15, 0
	(p6) br.cond.dpnt .L2901
	adds r39 = 2272, r13
	br.call.sptk.many b0 = __ia64_load_fpu#
	;;
	ld8 r14 = [r36]
	;;
	and r14 = -33, r14
	;;
	st8 [r36] = r14
	br .L2880
.L2901:
	br.call.sptk.many b0 = __ia64_init_fpu#
	;;
	ld8 r14 = [r36]
	;;
	or r14 = 32, r14
	;;
	st8 [r36] = r14
	br .L2880
.L2890:
	adds r34 = 144, r12
	addl r40 = @ltoff(.LC33), gp
	br .L2938
.L2903:
	ld8 r17 = [r36]
	;;
	mov r15 = r17
	;;
	extr.u r14 = r15, 32, 2
	;;
	cmp4.eq p6, p7 = 0, r14
	(p6) br.cond.dpnt .L2904
	extr.u r14 = r33, 4, 4
	adds r17 = 8, r36
	extr.u r15 = r15, 41, 2
	;;
	cmp.ne p6, p7 = 2, r14
	adds r16 = 20, r12
	adds r18 = 44, r12
	;;
	(p7) addl r39 = 11, r0
	adds r14 = 16, r12
	(p7) addl r35 = 196610, r0
	(p6) addl r39 = 4, r0
	(p6) addl r35 = 196610, r0
	mov r41 = r13
	;;
	st4 [r14] = r39
	adds r14 = 24, r12
	;;
	st4 [r14] = r35
	ld8 r14 = [r17]
	st4 [r16] = r0
	;;
	add r14 = r14, r15
	adds r17 = 32, r12
	;;
	st8 [r17] = r14
	adds r15 = 40, r12
	addl r16 = 1, r0
	;;
	st4 [r15] = r32
	adds r14 = 48, r12
	adds r15 = 16, r12
	st4 [r18] = r16
	;;
	mov r40 = r15
	st8 [r14] = r33
	br.call.sptk.many b0 = force_sig_info#
	;;
	br .L2880
.L2904:
	adds r14 = 8, r36
	;;
	ld8 r39 = [r14]
	br.call.sptk.many b0 = search_exception_table#
	;;
	cmp.eq p6, p7 = 0, r8
	;;
	(p6) mov r14 = r0
	(p6) br.cond.dpnt .L2910
	mov r40 = r8
	mov r39 = r36
	br.call.sptk.many b0 = handle_exception#
	;;
	addl r14 = 1, r0
	;;
.L2910:
	cmp4.eq p6, p7 = 0, r14
	(p7) br.cond.dptk .L2880
	adds r34 = 144, r12
	addl r40 = @ltoff(.LC34), gp
	br .L2938
.L2911:
	ld8 r17 = [r36]
	;;
	extr.u r14 = r17, 32, 2
	;;
	cmp4.eq p6, p7 = 0, r14
	(p6) br.cond.dpnt .L2912
	adds r14 = 16, r12
	addl r39 = 4, r0
	adds r16 = 24, r12
	;;
	st4 [r14] = r39
	adds r18 = 8, r36
	extr.u r17 = r17, 41, 2
	addl r14 = 196610, r0
	mov r41 = r13
	;;
	st4 [r16] = r14
	ld8 r15 = [r18]
	adds r14 = 20, r12
	adds r16 = 40, r12
	;;
	st4 [r14] = r0
	add r15 = r15, r17
	adds r14 = 32, r12
	;;
	st8 [r14] = r15
	st4 [r16] = r32
	adds r15 = 44, r12
	addl r14 = 1, r0
	;;
	st4 [r15] = r14
	adds r16 = 48, r12
	adds r15 = 16, r12
	;;
	st8 [r16] = r33
	br .L2939
.L2912:
	adds r34 = 144, r12
	addl r40 = @ltoff(.LC35), gp
	br .L2938
.L2915:
	cmp.eq p6, p7 = 35, r32
	;;
	(p6) adds r15 = 24, r12
	(p6) addl r14 = 196611, r0
	(p6) mov r34 = r0
	;;
	(p6) st4 [r15] = r14
	(p6) ld8 r17 = [r36]
	(p6) br.cond.dpnt .L2916
	cmp.ltu p6, p7 = 35, r32
	(p6) br.cond.dptk .L2923
	;;
	cmp.eq p6, p7 = 29, r32
	(p6) br.cond.dpnt .L2917
	ld8 r17 = [r36]
	br .L2916
	;;
.L2923:
	cmp.eq p6, p7 = 36, r32
	;;
	(p6) adds r15 = 24, r12
	(p6) addl r14 = 196610, r0
	(p6) mov r34 = r0
	;;
	(p6) st4 [r15] = r14
	(p6) ld8 r17 = [r36]
	(p6) br.cond.dpnt .L2916
	;;
	ld8 r17 = [r36]
	br .L2916
.L2917:
	addl r14 = 196612, r0
	;;
	ld8 r17 = [r36]
	adds r15 = 24, r12
	;;
	st4 [r15] = r14
	tbit.nz p6, p7 = r17, 34
	;;
	(p7) adds r14 = 8, r36
	;;
	(p7) ld8 r34 = [r14]
.L2916:
	extr.u r14 = r17, 32, 2
	;;
	cmp4.ne p6, p7 = 0, r14
	(p6) br.cond.dptk .L2924
	mov r40 = r32
	mov r41 = r36
	addl r39 = 4, r0
	br.call.sptk.many b0 = kdb#
	;;
	cmp4.eq p6, p7 = 0, r8
	(p7) br.cond.dptk .L2880
.L2924:
	adds r16 = 16, r12
	addl r39 = 5, r0
	adds r15 = 44, r12
	;;
	mov r14 = r16
	adds r17 = 48, r12
	adds r18 = 32, r12
	;;
	st4 [r14] = r39, 4
	adds r16 = 40, r12
	mov r41 = r13
	;;
	st4 [r14] = r0
	st4 [r15] = r0
	adds r14 = 16, r12
	st8 [r17] = r0
	;;
	mov r40 = r14
	st8 [r18] = r34
	br .L2940
.L2926:
	cmp.eq p6, p7 = 32, r32
	;;
	mov r40 = r36
	mov r41 = r33
	(p6) addl r39 = 1, r0
	(p7) mov r39 = r0
	br.call.sptk.many b0 = handle_fpu_swa#
	;;
	cmp4.gt p6, p7 = r0, r8
	(p6) br.cond.dpnt .L2928
	adds r14 = 1496, r13
	;;
	ld8 r15 = [r14]
	;;
	tbit.nz p6, p7 = r15, 7
	(p7) br.cond.dpnt .L2880
.L2928:
	adds r15 = 16, r12
	addl r39 = 8, r0
	adds r17 = 8, r36
	;;
	mov r14 = r15
	adds r18 = 24, r12
	mov r41 = r13
	ld8 r15 = [r36]
	;;
	st4 [r14] = r39, 4
	extr.u r15 = r15, 41, 2
	;;
	st4 [r14] = r0
	ld8 r16 = [r17]
	addl r14 = 196615, r0
	;;
	st4 [r18] = r14
	add r16 = r16, r15
	adds r17 = 32, r12
	;;
	st8 [r17] = r16
	addl r14 = 1, r0
	adds r15 = 44, r12
	;;
	st4 [r15] = r14
	adds r18 = 48, r12
	adds r16 = 40, r12
	adds r14 = 16, r12
	;;
	st8 [r18] = r33
	mov r40 = r14
.L2940:
	st4 [r16] = r0
	br.call.sptk.many b0 = force_sig_info#
	;;
	br .L2880
.L2929:
	ld8 r20 = [r36]
	;;
	extr.u r14 = r20, 32, 2
	;;
	cmp4.eq p6, p7 = 0, r14
	(p6) br.cond.dpnt .L2930
	adds r15 = 16, r12
	addl r39 = 4, r0
	adds r16 = 24, r12
	;;
	st4 [r15] = r39
	addl r14 = 196617, r0
	adds r17 = 20, r12
	;;
	st4 [r16] = r14
	adds r15 = 8, r36
	adds r18 = 44, r12
	st4 [r17] = r0
	adds r19 = 48, r12
	extr.u r16 = r20, 41, 2
	;;
	ld8 r14 = [r15]
	mov r41 = r13
	st4 [r18] = r0
	adds r15 = 40, r12
	;;
	add r14 = r14, r16
	st8 [r19] = r0
	adds r16 = 32, r12
	st4 [r15] = r0
	adds r15 = 16, r12
	;;
	st8 [r16] = r14
.L2939:
	mov r40 = r15
	br.call.sptk.many b0 = force_sig_info#
	;;
	br .L2880
.L2930:
	adds r34 = 144, r12
	addl r40 = @ltoff(.LC36), gp
	;;
.L2938:
	mov r39 = r34
	ld8 r40 = [r40]
	br.call.sptk.many b0 = sprintf#
	;;
	br .L2882
.L2931:
	mov r39 = r36
	mov r40 = r33
	br.call.sptk.many b0 = ia32_exception#
	;;
	cmp4.ne p6, p7 = 0, r8
	(p7) br.cond.dpnt .L2880
	addl r39 = @ltoff(.LC37), gp
	;;
	ld8 r39 = [r39]
	br.call.sptk.many b0 = printk#
	;;
	addl r39 = @ltoff(.LC38), gp
	adds r14 = 8, r36
	mov r41 = r34
	;;
	ld8 r40 = [r14]
	ld8 r39 = [r39]
	mov r42 = r33
	br.call.sptk.many b0 = printk#
	;;
	addl r39 = 11, r0
	mov r40 = r13
	br.call.sptk.many b0 = force_sig#
	;;
	adds r34 = 144, r12
	br .L2882
.L2933:
	mov r39 = r36
	mov r40 = r33
	br.call.sptk.many b0 = ia32_intercept#
	;;
	cmp4.ne p6, p7 = 0, r8
	(p7) br.cond.dpnt .L2880
	addl r39 = @ltoff(.LC39), gp
	;;
	ld8 r39 = [r39]
	br.call.sptk.many b0 = printk#
	;;
	adds r14 = 8, r36
	addl r39 = @ltoff(.LC40), gp
	mov r41 = r34
	;;
	ld8 r40 = [r14]
	ld8 r39 = [r39]
	mov r42 = r33
	mov r43 = r35
	br.call.sptk.many b0 = printk#
	;;
	addl r39 = 11, r0
	mov r40 = r13
	br.call.sptk.many b0 = force_sig#
	;;
	br .L2880
.L2935:
	adds r34 = 144, r12
	addl r40 = @ltoff(.LC41), gp
	shr.u r41 = r33, 16
	;;
	mov r39 = r34
	ld8 r40 = [r40]
	br.call.sptk.many b0 = sprintf#
	;;
	br .L2882
.L2936:
	adds r34 = 144, r12
	addl r40 = @ltoff(.LC42), gp
	mov r41 = r32
	;;
	mov r39 = r34
	ld8 r40 = [r40]
	br.call.sptk.many b0 = sprintf#
	;;
.L2882:
	mov r39 = r34
	mov r40 = r36
	mov r41 = r33
	br.call.sptk.many b0 = die_if_kernel#
	;;
	addl r39 = 4, r0
	mov r40 = r13
	br.call.sptk.many b0 = force_sig#
	;;
.L2880:
	mov ar.pfs = r38
	mov b0 = r37
	.restore sp
	adds r12 = 256, r12
	br.ret.sptk.many b0
	.endp ia64_fault#

Re: [Linux-ia64] Re: gas generates incorrect ia64 unwind rlen values

[David Mosberger]

  Keith> I used gcc 2.96 20000731 (Red Hat Linux 7.1 2.96-101) to
  Keith> convert traps.c to traps.S, then extracted the headers and
  Keith> ia64_fault for testing against gas.  traps.S only has one
  Keith> body.  I wanted to avoid dumping 530+ lines to the list but
  Keith> ...

  Keith> Interesting that a different gcc which generates two bodies
  Keith> gets valid unwind data, but this code with only one body
  Keith> generates invalid unwind data.  David, what does your unwind
  Keith> data look like after assembling this code?

Why do you insist on re-discovering old bugs?  For the code in
question, the problem is caused by the jump-table generated for the
switch-statement.  gcc 2.9x placed jump-tables in the text section,
which violates the ia64 ABI and also confuses the assembler.

	--david

Re: [Linux-ia64] Re: gas generates incorrect ia64 unwind rlen values

[Keith Owens]

On Mon, 16 Dec 2002 19:25:39 -0800, 
David Mosberger <davidm@napali.hpl.hp.com> wrote:
>Why do you insist on re-discovering old bugs?  For the code in
>question, the problem is caused by the jump-table generated for the
>switch-statement.  gcc 2.9x placed jump-tables in the text section,
>which violates the ia64 ABI and also confuses the assembler.

Which version of gcc to use is not my decision, I have to use 2.96 :(.
Thanks anyway.

[Linux-ia64] Re: gas generates incorrect ia64 unwind rlen values

[Patil, Harish]

>>>>> Mon, 16 Dec 2002 14:08:43 -0800, David Mosberger
<davidm@napali.hpl.hp.com> said:
> There have been many unwind-related bug fixes to the toolchain.  It's
> one reason why 2.9x is hopelessly obsolete.  Distros should really
> switch to gcc-3.2.
>	--david

David:

I have a RHAS kernel compiled with *gcc3.2*. Using a script based on
readelf/objdmp I found out that there are 7 instances in this kernel where
'rlen' may be wrong. The invariant the script is looking for is this:
	Sum(rlen for various regions) = Number of slots in the code range.

The script found following violations of the invariant:

<ia64_trace_syscall>: [0xe00000000440e1a0-0xe00000000440e240), info at
+0x54cdd8
        lo =  440E1A0  hi = 440E240
        sum_rlen =  28 no_slots = 30
            *******ERROR ***********
            sum_rlen: 28  != no_slots:30
<ia64_ret_from_clone>: [0xe00000000440e240-0xe00000000440e270), info at
+0x54ce08
        lo =  440E240  hi = 440E270
        sum_rlen =  7 no_slots = 9
            *******ERROR ***********
            sum_rlen: 7  != no_slots:9
<ia64_prepare_handle_unaligned>: [0xe00000000440e7a0-0xe00000000440e800),
info at +0x54cf70
        lo =  440E7A0  hi = 440E800
        sum_rlen =  17 no_slots = 18
            *******ERROR ***********
            sum_rlen: 17  != no_slots:18
<ia32_ret_from_clone>: [0xe0000000044506a0-0xe0000000044506d0), info at
+0x54fd00
        lo =  44506A0  hi = 44506D0
        sum_rlen =  7 no_slots = 9
            *******ERROR ***********
            sum_rlen: 7  != no_slots:9
<memset>: [0xe0000000049338a0-0xe000000004933cc0), info at +0x5803d0
        lo =  49338A0  hi = 4933CC0
        sum_rlen =  195 no_slots = 198
            *******ERROR ***********
            sum_rlen: 195  != no_slots:198
<memcpy>: [0xe0000000049365a0-0xe000000004936a40), info at +0x580618
        lo =  49365A0  hi = 4936A40
        sum_rlen =  219 no_slots = 222
            *******ERROR ***********
            sum_rlen: 219  != no_slots:222
code_range= 0xe000000004b18000-0xe000000004b182b0
        lo =  4B18000  hi = 4B182B0
        sum_rlen =  130 no_slots = 129
            *******ERROR ***********
            sum_rlen: 130  != no_slots:129

-Harish

Re: [Linux-ia64] Re: gas generates incorrect ia64 unwind rlen values

[David Mosberger]

>>>>> On Tue, 17 Dec 2002 08:33:38 -0800, "Patil, Harish" <harish.patil@intel.com> said:

  Harish> I have a RHAS kernel compiled with *gcc3.2*. Using a script
  Harish> based on readelf/objdmp I found out that there are 7
  Harish> instances in this kernel where 'rlen' may be wrong. The
  Harish> invariant the script is looking for is this: Sum(rlen for
  Harish> various regions) = Number of slots in the code range.

  Harish> The script found following violations of the invariant:

  Harish> <ia64_trace_syscall>:
  Harish> <ia64_ret_from_clone>:
  Harish> <ia64_prepare_handle_unaligned>:
  Harish> <ia32_ret_from_clone>:
  Harish> <memset>:
  Harish> <memcpy>:

These are all handwritten assembly routines.  I think I see what's wrong:

 (a) for the first 4 routines, note how they all start with an empty
     prologue (e.g., PT_REGS_UNWIND_INFO(0)); these empty prologues
     seem to cause gas to not count the "nop"s at the beginning of the
     code. Or perhaps gas never counts the starting "nop"s and this is
     just one of the places where the first instruction cannot go into
     the first slot of a bundle.

 (b) for memcpy and memset, I suspect the ".align 32" directives are
     confusing gas

(a) is probably a bug in gas.  For (b), gas can't guarantee much
because (in general) it can't know the alignment of the first
instruction of a procedure (not beyond the minimum of 16 bytes).  We
should fix the assembly source here (use label_state/copy_state around
the .align directives, or get rid of them alltogether).  One thing we
could do in gas, however, is add a warning so that a programmer will
know when s/he accidentally uses a .align directive inside a region.

  Harish> code_range= 0xe000000004b18000-0xe000000004b182b0
  Harish>         lo =  4B18000  hi = 4B182B0
  Harish>         sum_rlen =  130 no_slots = 129
  Harish>             *******ERROR ***********
  Harish>             sum_rlen: 130  != no_slots:129

Do you know what code this is?  The addresses are not terribly useful
because they'll vary from one kernel to another.

Is your script fully automatic?  If so, perhaps we could add it to the
kernel sources and run it as part of "make check".  I'd love to have
better unwind-info checking tools.  Actually, it's even more important
to use such tools to verify the correctness of the user-level unwind
info.

Someone wants to volunteer to fix this stuff?

	--david

RE: [Linux-ia64] Re: gas generates incorrect ia64 unwind rlen val

[Patil, Harish]

> From: David Mosberger [mailto:davidm@napali.hpl.hp.com]
> Sent: Thursday, December 19, 2002 3:19 PM
> To: Patil, Harish
> Cc: 'davidm@hpl.hp.com'; 'linux-ia64@linuxia64.org'
> Subject: Re: [Linux-ia64] Re: gas generates incorrect ia64 unwind rlen
> values
> 
> 
> >>>>> On Tue, 17 Dec 2002 08:33:38 -0800, "Patil, Harish" 
> <harish.patil@intel.com> said:
> 
>   Harish> I have a RHAS kernel compiled with *gcc3.2*. Using a script
>   Harish> based on readelf/objdmp I found out that there are 7
>   Harish> instances in this kernel where 'rlen' may be wrong. The
>   Harish> invariant the script is looking for is this: Sum(rlen for
>   Harish> various regions) = Number of slots in the code range.
> 
>   Harish> The script found following violations of the invariant:

<stuff deleted>

> 
>   Harish> code_range= 0xe000000004b18000-0xe000000004b182b0
>   Harish>         lo =  4B18000  hi = 4B182B0
>   Harish>         sum_rlen =  130 no_slots = 129
>   Harish>             *******ERROR ***********
>   Harish>             sum_rlen: 130  != no_slots:129
> 
> Do you know what code this is?  The addresses are not terribly useful
> because they'll vary from one kernel to another.

Sorry, the procedure name somehow got lost.. I disassembled the image and
the relevant procedure is:  <ia64_sigtramp>

> Is your script fully automatic?  If so, perhaps we could add it to the
> kernel sources and run it as part of "make check".  I'd love to have
> better unwind-info checking tools.  Actually, it's even more important
> to use such tools to verify the correctness of the user-level unwind
> info.

Yes, the script is fully automatic and is included below (requires a
'readelf' that 
understands "-u" option).

-Harish
<----------- BEGIN unwcheck.sh
#!/bin/sh 
#   Usage: unwcheck.sh <executable_file_name>
#   Pre-requisite: readelf [from Gnu binutils package]
#   Purpose: Check the following invariant
#       For each code range in the input binary:
#          Sum[ lengths of unwind regions] = Number of slots in code range.
#   Author : Harish Patil
#   First version: January 2002
#   Modified : 2/13/2002
#   Modified : 3/15/2002: duplicate detection
readelf -u $1 | gawk '\
 function todec(hexstr){
    dec = 0;
    l = length(hexstr);
    for (i = 1; i <= l; i++)
    {
        c = substr(hexstr, i, 1);
        if (c = "A")
            dec = dec*16 + 10;
        else if (c = "B")
            dec = dec*16 + 11;
        else if (c = "C")
            dec = dec*16 + 12;
        else if (c = "D")
            dec = dec*16 + 13;
        else if (c = "E")
            dec = dec*16 + 14;
        else if (c = "F")
            dec = dec*16 + 15;
        else 
            dec = dec*16 + c;
    }
    return dec;
 }
 BEGIN { first = 1; sum_rlen = 0; no_slots = 0; errors=0; no_code_ranges=0;
}
 {
   if (NF=5 && $3="info")
   {
      no_code_ranges += 1;
      if (first = 0)
      {
         if (sum_rlen != no_slots) 
         {
            print full_code_range;
            print "       ", "lo = ", lo, " hi =", hi;
            print "       ", "sum_rlen = ", sum_rlen, "no_slots = "
no_slots;
            print "       ","   ", "*******ERROR ***********";
            print "       ","   ", "sum_rlen:", sum_rlen, " != no_slots:"
no_slots;
            errors += 1;
         }
         sum_rlen = 0;
      }
      full_code_range =  $0;
      code_range =  $2;
      gsub("),", "", code_range);
      gsub("^.", "", code_range);
      split(code_range, addr, "-");
      lo = toupper(addr[1]);

      code_range_lo[no_code_ranges] = addr[1];
      occurs[addr[1]] += 1;
      full_range[addr[1]] = $0;

      gsub("0X.[0]*", "", lo);
      hi = toupper(addr[2]);
      gsub("0X.[0]*", "", hi);
      no_slots = (todec(hi) - todec(lo))/ 16*3
      first = 0;
   }
   if (index($0,"rlen") > 0 )
   {
    rlen_str =  substr($0, index($0,"rlen"));
    rlen = rlen_str;
    gsub("rlen=", "", rlen);
    gsub(")", "", rlen);
    sum_rlen = sum_rlen +  rlen;
   }
  }
  END {
      if (first = 0)
      {
         if (sum_rlen != no_slots) 
         {
            print "code_range=", code_range;
            print "       ", "lo = ", lo, " hi =", hi;
            print "       ", "sum_rlen = ", sum_rlen, "no_slots = "
no_slots;
            print "       ","   ", "*******ERROR ***********";
            print "       ","   ", "sum_rlen:", sum_rlen, " != no_slots:"
no_slots;
            errors += 1;
         }
      }
    no_duplicates = 0;
    for (i=1; i<=no_code_ranges; i++)
    {
        cr = code_range_lo[i];
        if (reported_cr[cr]=1) continue;
        if ( occurs[cr] > 1)
        {
            reported_cr[cr] = 1;
            print "Code range low ", code_range_lo[i], ":", full_range[cr],
" occurs: ", occurs[cr], " times.";
            print " ";
            no_duplicates++;
        }
    }
    print "==================="
    print "Total errors:", errors, "/", no_code_ranges, " duplicates:",
no_duplicates;
    print "==================="
  }
  '
---> END unwcheck.sh [note the "'" (single quote) on the last line ]

RE: [Linux-ia64] Re: gas generates incorrect ia64 unwind rlen val

[David Mosberger]

>>>>> On Thu, 19 Dec 2002 17:46:54 -0800, "Patil, Harish" <harish.patil@intel.com> said:

  >> From: David Mosberger [mailto:davidm@napali.hpl.hp.com]
  >> Sent: Thursday, December 19, 2002 3:19 PM
  >> To: Patil, Harish
  >> Cc: 'davidm@hpl.hp.com'; 'linux-ia64@linuxia64.org'
  >> Subject: Re: [Linux-ia64] Re: gas generates incorrect ia64 unwind rlen
  >> values

  >> Is your script fully automatic?  If so, perhaps we could add it to the
  >> kernel sources and run it as part of "make check".  I'd love to have
  >> better unwind-info checking tools.  Actually, it's even more important
  >> to use such tools to verify the correctness of the user-level unwind
  >> info.

  Harish> Yes, the script is fully automatic and is included below (requires a
  Harish> 'readelf' that understands "-u" option).

OK, I checked this script into arch/ia64/scripts/unwcheck.sh now.  I
had to hack it a bit because readelf v2.13.90.0.10 generates the
code-ranges in the format:

	[0xe000000004408000-0xe000000004408230],

Which isn't what the script expected.

I also fixed the handful of problems it pointed out.  I agree that
those are really gas bugs (except perhaps for the unwind info in
gate.S, which was a bit clunky).  But for now, I fixed things by
adding explicit nop's and commenting out .align directives.  The
removal of .align may cost us a cycle or two in some routines, but I
don't it's noticable in practice.

Thanks,

	--david

Re: [Linux-ia64] Re: gas generates incorrect ia64 unwind rlen val ues

[Bjorn Helgaas]

On Friday 17 January 2003 7:30 pm, David Mosberger wrote:
> OK, I checked this script into arch/ia64/scripts/unwcheck.sh now. 
> ...
> I also fixed the handful of problems it pointed out.  I agree that
> those are really gas bugs (except perhaps for the unwind info in
> gate.S, which was a bit clunky).  But for now, I fixed things by
> adding explicit nop's and commenting out .align directives.  The
> removal of .align may cost us a cycle or two in some routines, but I
> don't it's noticable in practice.

I applied these changes to 2.4 as well.