From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14930 invoked by alias); 19 Jul 2010 10:59:17 -0000 Received: (qmail 14922 invoked by uid 22791); 19 Jul 2010 10:59:16 -0000 X-SWARE-Spam-Status: No, hits=-1.3 required=5.0 tests=AWL,BAYES_00,MSGID_FROM_MTA_HEADER,SPF_SOFTFAIL,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mtagate4.de.ibm.com (HELO mtagate4.de.ibm.com) (195.212.17.164) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 19 Jul 2010 10:59:10 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.13.1/8.13.1) with ESMTP id o6JAx7Cq007525 for ; Mon, 19 Jul 2010 10:59:07 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o6JAx70H1810534 for ; Mon, 19 Jul 2010 12:59:07 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id o6JAx6M4026016 for ; Mon, 19 Jul 2010 12:59:07 +0200 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with SMTP id o6JAx5r0026004; Mon, 19 Jul 2010 12:59:05 +0200 Message-Id: <201007191059.o6JAx5r0026004@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Mon, 19 Jul 2010 12:59:05 +0200 Subject: Re: ARM prologue parsing support for Thumb-2 instructions? To: matthew.gretton-dann@arm.com (Matthew Gretton-Dann) Date: Mon, 19 Jul 2010 10:59:00 -0000 From: "Ulrich Weigand" Cc: gdb@sourceware.org, rearnsha@arm.com (Richard Earnshaw), dan@codesourcery.com In-Reply-To: <1279529477.3466.25.camel@e102319-lin.cambridge.arm.com> from "Matthew Gretton-Dann" at Jul 19, 2010 09:51:17 AM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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/msg00072.txt.bz2 Matthew Gretton-Dann wrote: > 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. Actually, it seems I misspoke here; I intended to refer to arm_scan_prologue where I wrote arm_analyze_prologue. GDB is in fact then calling down to thumb_analyze_prologue, not arm_analyze_prologue, in my test. So at least in the test case I'm looking at, instruction state detection does not appear to be the problem ... > 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. Thanks for the tip. This patch did go upstream a while ago and is already included in the pre-7.2 GDB I was testing. > Trunk thumb_analyze_prologue does have support for Thumb-2. Well, all the support for Thumb-2 I can see is in this block: else if ((insn & 0xe000) == 0xe000 && cache == NULL) { /* Only recognize 32-bit instructions for prologue skipping. */ which, as the comment says, is active *only* if this routine is called from arm_skip_prologue (with cache == NULL), but not if the routine is called from arm_scan_prologue (with cache != NULL), which is what is used during unwinding. > 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. That may or may not be an additional problem; right now during unwinding GDB doesn't even get beyond the very first instruction of a Thumb-2 prologue ... > 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. OK, I'll have a look. > 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 for the pointer! Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com