Strange bug in mremap/mremap_chunk

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

After installing glibc 2.1.3pre1, I found that gcc would not compile
itself anymore. Specifically, cpp 2.95.2 crashed when compiling
cp/ptree.c from current gcc CVS.

I traced this down to malloc.c:1966:

  cp = (char *)mremap((char *)p - offset, size + offset, new_size,
                      MREMAP_MAYMOVE);

  if (cp == MAP_FAILED) return 0;

  p = (mchunkptr)(cp + offset);

  assert(aligned_OK(chunk2mem(p)));

  assert((p->prev_size == offset));
  set_head(p, (new_size - offset)|IS_MMAPPED);

In the last line, p would be an invalid address (p=0x802e8000). I
found that this results from p being computed as (cp+offset), and
offset is stored in %edi. Before the call to malloc, offset is
0. After the call, it is not zero anymore, even though it should be a
callee-saves register. Here is the relevant snippet from gdb, starting
right after the int 0x80 system call had been executed:

(gdb) p $edi
$3 = 0
(gdb) x/10i $pc
0x400bbc09 <__mremap+25>:	popl   %ebx
0x400bbc0a <__mremap+26>:	popl   %esi
0x400bbc0b <__mremap+27>:	cmpl   $0xfffff001,%eax
0x400bbc10 <__mremap+32>:	jae    0x400bbc13 <__mremap+35>
0x400bbc12 <__mremap+34>:	ret    
0x400bbc13 <__mremap+35>:	pushl  %ebx
0x400bbc14 <__mremap+36>:	call   0x400bbc19 <__mremap+41>
0x400bbc19 <__mremap+41>:	popl   %ebx
0x400bbc1a <__mremap+42>:	xorl   %edx,%edx
0x400bbc1c <__mremap+44>:	addl   $0x3cc5f,%ebx
(gdb) si
0x400bbc0a in __mremap ()
(gdb) p/x $edi
$5 = 0x40174000
(gdb) p/x $eax
$6 = 0x40174000

As you can see, edi is 0, and the processor is going to perform 'popl
%ebx'. After that instruction is done, the value of edi is changed!!!
and it is the same as the value returned from the system call.

This is not a misinterpretation, as it results in the pointer returned
from mremap getting doubled by (cp+offset), which exactly corresponds
what I'm seeing later. However, I cannot understand how the pop
instruction affects edi...

The processor is an AMD-K6 350 MHz.

Any help appreciated.

Regards,
Martin