From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27968 invoked by alias); 19 Jul 2010 08:51:39 -0000 Received: (qmail 27954 invoked by uid 22791); 19 Jul 2010 08:51:37 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from cam-admin0.cambridge.arm.com (HELO cam-admin0.cambridge.arm.com) (217.140.96.50) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 19 Jul 2010 08:51:26 +0000 Received: from cam-owa2.Emea.Arm.com (cam-owa2.emea.arm.com [10.1.105.18]) by cam-admin0.cambridge.arm.com (8.12.6/8.12.6) with ESMTP id o6J8pID2028547; Mon, 19 Jul 2010 09:51:18 +0100 (BST) Received: from [10.1.77.63] ([10.1.255.212]) by cam-owa2.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Jul 2010 09:51:18 +0100 Subject: Re: ARM prologue parsing support for Thumb-2 instructions? From: Matthew Gretton-Dann To: Ulrich Weigand Cc: gdb@sourceware.org, Richard Earnshaw , dan@codesourcery.com In-Reply-To: <201007161703.o6GH3XoP011062@d12av02.megacenter.de.ibm.com> References: <201007161703.o6GH3XoP011062@d12av02.megacenter.de.ibm.com> Content-Type: text/plain; charset="ISO-8859-1" Date: Mon, 19 Jul 2010 08:51:00 -0000 Message-ID: <1279529477.3466.25.camel@e102319-lin.cambridge.arm.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2010-07/txt/msg00071.txt.bz2 Ulrich, On Fri, 2010-07-16 at 18:03 +0100, Ulrich Weigand wrote: > Hello, > > in testing GDB on an armv7l-linux-gnueabi board running Ubuntu > Maverick > I noticed serious problems with getting backtraces out of system > libraries. > > Looking into this, it turns out that arm_analyze_prologue appears to > have > no support at all for decoding Thumb-2 instructions. (There is some > support for Thumb-2 in arm_skip_prologue, but not for unwinding.) If gdb is using arm_analyze_prologue and not thumb_analyze_prologue for Thumb (1 or 2) code then gdb is not guessing the instruction state correctly. I submitted a patch earlier this year (http://sourceware.org/ml/gdb-patches/2010-03/msg00168.html) to try to improve gdb's heuristic for determining the instruction state which may help - although in that particular use case it was for single-stepping. Note though that it may just not be possible to make a 100% accurate statement without some form of debugging symbols present - just mapping symbols ($a, $d, $t) would be enough for determining the instruction set. > Since Thumb-2 is the default code generation option on this system, > this > makes it just about impossible to backtrace out of any code that does > not > come with debug information. Trunk thumb_analyze_prologue does have support for Thumb-2. However, thumb_analyze_prologue will stop analyzing the prologue as soon as it sees an instruction which it does not understand as part of a prologue sequence. This is the opposite from arm_analyze_prologue, which knows which non-prologue sequence instructions are safe to ignore and which are not. Fixing thumb_analyze_prologue to behave like arm_analyze_prologue is on my list of things to do, but it is not going to happen immediately. So if you want to have a go at fixing this please feel free. A related issue with backtracing through system calls is that inline syscalls in glibc corrupt the frame pointer (during the syscall) so that if you try to backtrace when at a syscall you get garbage. This was fixed in this glibc patch: http://sourceware.org/ml/libc-ports/2010-04/msg00001.html. Thanks, Matt -- Matthew Gretton-Dann Principal Engineer - PDSW Tools ARM Ltd