[lkml]   [2008]   [May]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC][PATCH] x86: don't destroy %rbp on kernel-mode faults
On Mon, May 19, 2008 at 11:16 PM, Andi Kleen <> wrote:
> Vegard Nossum wrote:
>> Hi,
>> The RFC part of this patch is: Does anybody see why touching %rcx would
>> be bad? It certainly looks like %ecx is free. This fixes the stacktrace
>> problem I was seeing, and Pekka tested a bootup to userspace. (Pekka also
>> did half of the debugging. When will git allow multiple authors for a
>> patch? :-))
> The patch is ok, but I'm sure there's lots of other assembler code that
> destroys %rbp when it was saved elsewhere.

Thanks, The real intention of this code (you might have guessed it)
was to fix kmemcheck on 64-bit, and it did, so I'm happy. If we (or
others) hit another similar case, I'm sure we'll be able to fix those

The problem seems to be that %rbp was never restored before it was
used again, and that's what I consider the real error in this case. I
changed it to use a different register for the temporary computation,
but restoring %rbp from wherever it was stored would also have been a
valid, albeit less efficient, solution.

> When I wrote all the assembler the assumption was always that a real
> unwinder would be used for backtraces, not frame pointer.

Hm, I am not sure exactly what a "real unwinder" would be. But I do
think it's fair to say that it is the assembly code in this case that
is violating the binary interface, and not the stack tracer code.


"The animistic metaphor of the bug that maliciously sneaked in while
the programmer was not looking is intellectually dishonest as it
disguises that the error is the programmer's own creation."
-- E. W. Dijkstra, EWD1036

 \ /
  Last update: 2008-05-22 14:09    [W:0.056 / U:3.048 seconds]
©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site