And another optimizer bug

[guyharris]

Converted from SourceForge issue 940212, submitted by guy_harris

tcp[0:2]>=79 and tcp[0:2]<=81

generates bad code in 0.8.3:

(000) ldh 12 jeq #0x800 jt 2 jf 12 (002) ldb 23 jeq #0x6 jt 4 jf 12 (004) ldh 20 jset #0x1fff jt 12 jf 6 (006) ldxb 4*([14]&0xf) (007) ldh x + 14 ldx #0x4f (009) jge x jt 10 jf 12 (010) jgt x jt 12 jf 11 (011) ret #68 (012) ret #0

but not in 0.4:

(000) ldh 12 jeq #0x800 jt 2 jf 11 (002) ldb 23 jeq #0x6 jt 4 jf 11 (004) ldh 20 jset #0x1fff jt 11 jf 6 (006) ldxb 4*([14]&0xf) (007) ldh x + 14 jge #0x4f jt 9 jf 11 (009) jgt #0x51 jt 11 jf 10 (010) ret #68 (011) ret #0

If you turn the optimizer off, the code is still different, but 0.8.3's code is correct.

[guyharris]

Submitted by guy_harris

Logged In: YES user_id=541179

This is probably the same bug as

% ./tcpdump -d 'ip[16:4] >= 3232235521 && ip[16:4] <= 3232235523' (000) ldh 12 jeq #0x800 jt 2 jf 7 (002) ld 30 ldx #0xc0a80001 (004) jge x jt 5 jf 7 (005) jgt x jt 7 jf 6 (006) ret #68 (007) ret #0

which I suspect is the cause of the problem reported in a winpcap-users thread with the subject "filtering ip ranges / bpf error ?":

http://www.mail-archive.com/winpcap-users@winpcap.polito.it/msg01493.html

[guyharris]

Submitted by guy_harris

Logged In: YES user_id=541179

The optimizer was eliminating blocks where no value computed in the block was used and the accumulator wasn't given a value it didn't already have, even if the index register was given a value it didn't already have; unfortunately, that doesn't work if you're comparing against the value in the index register in the test at the end of the block. I've checked in a change to check whether the index register is being given a value that it didn't already have.

And, yes, that is the same bug.