From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-patches-return-76412-listarch-gdb-patches=sources.redhat.com@sourceware.org>
Received: (qmail 22300 invoked by alias); 14 Nov 2010 12:19:45 -0000
Received: (qmail 22291 invoked by uid 22791); 14 Nov 2010 12:19:43 -0000
X-SWARE-Spam-Status: No, hits=-1.2 required=5.0	tests=AWL,BAYES_00,MSGID_MULTIPLE_AT
X-Spam-Check-By: sourceware.org
Received: from mailhost.u-strasbg.fr (HELO mailhost.u-strasbg.fr) (130.79.200.158)    by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 14 Nov 2010 12:19:39 +0000
Received: from md1.u-strasbg.fr (md1.u-strasbg.fr [IPv6:2001:660:2402::186])           by mailhost.u-strasbg.fr (8.14.3/jtpda-5.5pre1) with ESMTP id oAECJVro061132           ; Sun, 14 Nov 2010 13:19:32 +0100 (CET) (envelope-from pierre.muller@ics-cnrs.unistra.fr)
Received: from mailserver.u-strasbg.fr (ms2.u-strasbg.fr [IPv6:2001:660:2402:d::11])           by md1.u-strasbg.fr (8.14.4/jtpda-5.5pre1) with ESMTP id oAECJVtk063054           ; Sun, 14 Nov 2010 13:19:31 +0100 (CET) (envelope-from pierre.muller@ics-cnrs.unistra.fr)
Received: from E6510Muller (lec67-4-82-230-53-140.fbx.proxad.net [82.230.53.140]) (user=mullerp mech=LOGIN)          by mailserver.u-strasbg.fr (8.14.4/jtpda-5.5pre1) with ESMTP id oAECJSt1084545 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO)          ; Sun, 14 Nov 2010 13:19:29 +0100 (CET) (envelope-from pierre.muller@ics-cnrs.unistra.fr)
From: "Pierre Muller" <pierre.muller@ics-cnrs.unistra.fr>
To: "'Ulrich Weigand'" <uweigand@de.ibm.com>,        "'Daniel Jacobowitz'" <dan@codesourcery.com>
Cc: <gdb-patches@sourceware.org>
Subject: [RFC] About arm-tdep.c arm_in_function_epilogue_p function
Date: Sun, 14 Nov 2010 12:19:00 -0000
Message-ID: <002701cb83f6$30b394e0$921abea0$@muller@ics-cnrs.unistra.fr>
MIME-Version: 1.0
Content-Type: text/plain;	charset="us-ascii"
Content-Transfer-Encoding: 7bit
Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb-patches.sourceware.org>
List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb-patches/>
List-Post: <mailto:gdb-patches@sourceware.org>
List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-patches-owner@sourceware.org
X-SW-Source: 2010-11/txt/msg00169.txt.bz2

  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