Re: [Re: Possible Bug]

["Martin v. Loewis" <martin at loewis dot home dot cs dot tu-berlin dot de>]

> Whoops...The enclosure is now enclosed.

I have two problems with that report. 

One, the assembler file  you've included apparently was generated from
a  different source  code than  the source  code you've  included. For
example, the preprocessor output  contains a printk statement printing
"%s Intr:  Status Reg == %x  \n". The assembler file  contains no such
string.

Second, I really cannot see any problem with the generated code. As
far as I understand, the problem is that, inside Int_Handler, it
prints a value of 70 for status_reg, which you claim cannot occur, and
which therefore you assume is cached somehow in gcc.

Please follow me in my analysis of the generated assembler code, and
let me know where I erred. I'll attach the assembler file generated by
gcc 2.95.2 -O2 for reference.

Inside Int_Handler, we have

	movl $776,-8(%ebp)

So ebp[-8] now is 0x300+8. You first fetch cntrl_reg, then status_reg;
the latter compiles to

	movl -8(%ebp),%edx
#APP
	inb %dx,%al
outb %al,$0x80
#NO_APP
	andl $255,%eax
	movb %al,-9(%ebp)
	movb -9(%ebp),%al
	testl $16,%eax
	jne .L1242

Here, ebp[-8] is put into edx, and edx is used for the inb. So gcc
really fetches the value from the port. Afterwards, it is truncated to
8 bit, and put into ebp[-9]. From there it is fetched and checked for
(bReg & 0x10). If the check fails, we continue at L1242.

.L1242:
	addl $-4,%esp
	movb -9(%ebp),%al
	andl $255,%eax
	pushl %eax
	pushl $.LC10
	pushl $.LC46
	call printk_R1b7d4074

Here, the value from ebp[-9] is read into eax and put on the stack,
followed by the other printk arguments. I really cannot see anything
wrong with that assembler code.

Regards,
Martin

das1400.s.gz