This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
[RFC] About arm-tdep.c arm_in_function_epilogue_p function
- From: "Pierre Muller" <pierre dot muller at ics-cnrs dot unistra dot fr>
- To: "'Ulrich Weigand'" <uweigand at de dot ibm dot com>, "'Daniel Jacobowitz'" <dan at codesourcery dot com>
- Cc: <gdb-patches at sourceware dot org>
- Date: Sun, 14 Nov 2010 13:19:29 +0100
- Subject: [RFC] About arm-tdep.c arm_in_function_epilogue_p function
In the second part of that function,
for which II just committed an obvious
compilation failure fix, I found something
strange:
found_stack_adjust = 0;
insn = read_memory_unsigned_integer (pc - 4, 4, byte_order_for_code);
if (bits (insn, 28, 31) != INST_NV)
{
if ((insn & 0x0df0f000) == 0x0080d000)
/* ADD SP (register or immediate). */
found_stack_adjust = 1;
else if ((insn & 0x0df0f000) == 0x0040d000)
/* SUB SP (register or immediate). */
found_stack_adjust = 1;
else if ((insn & 0x0ffffff0) == 0x01a0d000)
/* MOV SP. */
>>> This line seems weird:
>>> why should a MOV SP be considered as a return?
>>> It should rather be a change in stack, no?
>>> (but I know about nothing about ARM instructions...)
>>> Furthermore, found_return isn't used
>>> anymore in that function.
>>> Isn't the correct code
>>> found_stack_adjust = 1;
found_return = 1;
else if ((insn & 0x0fff0000) == 0x08bd0000)
/* POP (LDMIA). */
found_stack_adjust = 1;
}
if (found_stack_adjust)
return 1;
return 0;
}
Ulrich or Daniel,
could one of you two check this and
commit a fix if I am right?
Thanks in advance,
Pierre Muller
GDB pascal language maintainer