From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 59382 invoked by alias); 29 Jun 2016 11:56:06 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 59361 invoked by uid 89); 29 Jun 2016 11:56:05 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.2 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:2084 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 29 Jun 2016 11:55:55 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id DE38E80086; Wed, 29 Jun 2016 11:55:53 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u5TBtqBE025481; Wed, 29 Jun 2016 07:55:53 -0400 Subject: Re: [PATCH] Skip gdb.base/func-ptrs.exp in thumb mode To: Yao Qi , "Maciej W. Rozycki" References: <1465812702-22061-1-git-send-email-yao.qi@linaro.org> Cc: "gdb-patches@sourceware.org" From: Pedro Alves Message-ID: <7898dd6b-7898-44e7-104e-fca326c0b1a7@redhat.com> Date: Wed, 29 Jun 2016 11:56:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-06/txt/msg00506.txt.bz2 On 06/29/2016 09:39 AM, Yao Qi wrote: > On Wed, Jun 22, 2016 at 8:04 PM, Maciej W. Rozycki wrote: >> >> So how does this work for indirect calls, such as ones made via function >> pointers, with the ARM target? With dynamic reassignment such a pointer >> can change at the run time and with mixed code it can point to regular ARM >> code sometimes and at other times it can point to Thumb code, still within >> the same execution of a program. Can't GDB reproduce the same actions? >> What do GCC/GAS/LD do with function pointer assignments that GDB can't? > > On ARM target, instruction "blx rm" is generated for indirect call, and "rm" has > the target address, plus ISA bit if needed. If the target function is ARM code, > "rm" has the target function address, otherwise, it has the thumb > target function > address with LSB set. I want to make it clear that, although thumb function > symbol value has LSB set, which only indicates this is a thumb function, the > function address is still 2-byte aligned. All these ISA bit set/clear > is managed > by LD. I think the question is what happens at run time, when a function pointer is set to a thumb function. Say, with something like this: typedef void (func_ptr) (void); void arm_function (void); void thumb_function (void); // add whatever __attribute__ necessary // for thumb. func_ptr *ptr; void foo (void) { ptr = thumb_function; ptr (); // stop here } Does "ptr" hold an address with the LSB set at run time, somehow? I assume it does. Then, doesn't this in gdb: (gdb) print ptr = thumb_function end up with the same value (LSB set)? If not, seems like that's a bug. Note that from the original commit log, one can't tell what exactly goes wrong in the test that requires skipping it. It talks in terms of Maciej's patch, and how some prototype based on that behaves, and not in terms of what is wrong with the current support, or if there's something the test is doing that is fundamentally impossible to do on arm. Thanks, Pedro Alves