On Wed, 18 Jun 2008, Linus Torvalds wrote:
>
> and that "lea" is doing an address computation of "eax+2*ebx-2". Which
> does *not* look like an address to a 32-bit entity, but to a 16-bit one.
> Yeah, it's not conclusive, but it is suggestive.
I'm wrong, that's just "eax+ebx-2". The *2 was just a brainfart on my
part.
But I think I have pinpointed where it comes from: it's the
struct dx_map_entry *map;
which is a structure like this:
struct dx_map_entry
{
u32 hash;
u16 offs;
u16 size;
};
and it does look like it's the
if (size + map[i].size/2 > blocksize/2)
calculation, where "i" counts backwards from "count-1" to 0.
In particular, the code
27: 8d 4c 18 fe lea 0xfffffffe(%eax,%ebx,1),%ecx
2b:* 8b 19 mov (%ecx),%ebx <-- trapping instruction
2d: 83 e9 08 sub $0x8,%ecx
30: 89 d8 mov %ebx,%eax
32: 66 d1 e8 shr %ax
38: 8d 04 02 lea (%edx,%eax,1),%eax
seems to be that "size + map[i].size/2" calculation, but I have a hard
time trying to line it up with wat _my_ compiler gives me. But the nearest
match I have is:
movw 6(%ecx), %bx # <variable>.size, D.21305
subl $8, %ecx #, ivtmp.921
movl -104(%ebp), %edx # blocksize, tmp179
movl %ebx, %eax # D.21305, tmp176
shrw %ax # tmp176
movzwl %ax, %eax # tmp176, tmp177
leal (%esi,%eax), %eax #, tmp178
which seems to be largely the same thing (except I have a "movw" to load
the size, and %ecx is offset by one 'map' entry - so the offset is 6 (in
the memop) instead of that "-2" (from the lea).
I think I'll give up, but that's the closest match I can find. No
guarantees, but it seems to support the notion of "wrong 32-bit load where
it should have used a 16-bit one".
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
