https://bugs.kde.org/show_bug.cgi?id=296166

Paul Carpenter <paul.m.carpenter1@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |paul.m.carpenter1@gmail.com

--- Comment #1 from Paul Carpenter <paul.m.carpenter1@gmail.com> ---
All going well, I should be able to submit a patch in the next few days.  It
needs some tidying up first.  This is what I believe needs changing:

1) Support leaf functions that do not use the stack.  This is the fix Chris
mentioned.   As it stands, sgcheck pushes the caller's stack frame when it
reaches a function call, and it pops the stack frame when the stack pointer is
reset.  This is OK for x86, since, I believe, every function uses the stack. 
On ARM, however, a small leaf function may not use the stack, so sgcheck won't
see its return.  The best thing to do seems to be to add a 'creation_ip' field
to _StackFrame, giving the address of the corresponding call instruction.  On
ARM, on function return, if the target address is the instruction after
creation_ip for the innermost stack frame, then it should be recognised as the
function return. 

2) Describe the frame pointer (R11) in VEX/priv/guest_arm_helpers.c.  This is
the only proposed change outside the exp-sgcheck/ directory.

3) Use a maximum of four arguments per helper call.  Argument marshalling for
ARM only supports four arguments (see the comment at the top of doHelperCall in
VEX/priv/host_arm_isel.c).  Four arguments is enough for the standard tools
such as memcheck, and it seems sensible for now to work around this limitation,
rather than fixing it.

4) Ignore load linked and store conditional instructions.  Since it is an
experimental tool, there is probably no need to support these instructions
properly, but "the impossible" was happening somewhere inside the C library.

All regression tests except 'stackerr' are passing on ARM.  The correct output
for stackerr already depends on the architecture (AMD vs Intel).  Although the
output on ARM matches neither, it looks plausible.

-- 
You are receiving this mail because:
You are watching all bug changes.