From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4841 invoked by alias); 28 Oct 2016 16:20:48 -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 4320 invoked by uid 89); 28 Oct 2016 16:20:48 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=H*Ad:U*uweigand, hooks, adapt, our X-HELO: mail-qt0-f193.google.com Received: from mail-qt0-f193.google.com (HELO mail-qt0-f193.google.com) (209.85.216.193) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 28 Oct 2016 16:20:38 +0000 Received: by mail-qt0-f193.google.com with SMTP id 12so2573290qtm.0 for ; Fri, 28 Oct 2016 09:20:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=LuB6ACgXvtvCbIq8Kwh8ktGCn/t57lhhok2auSpkjbA=; b=M0SfFmsIYOsZ/1P85tnD0jEWHHLRbqrIxSZ2VSRD5cz33thb8hbn2/UmM3pkElznjU J9IIasSpfByBlrqcmUc/0x56yn42DKoAoz1gbKsZV/FJzgGjXo5yYNSvXCgPs4CngYEm uz3sRpuiIdcg8SSxz6WWN1nYzMKBr+Q7KiB8AX738NQYpuoDgXWN0rgvftjUW0wg96dl OmwFOnXCmSpaKXlvZZEg7wjj23sWiqJ+e2h6tfSA5XCMtTG9SBAZbgb4jFKR0pjuEAlq PPtaHSBc1Dn61enVB2xqFZxR2AIA23xZj72p0EuuKNpa9clqEe2AYDpl8XH152oi0hR4 TYNQ== X-Gm-Message-State: ABUngvd7yvX7t0IrT3RZqUtmo7tMbIGufZg92VfWU8cF8a76SkJ39/ts2ZjOd7p80nPykq88RztcDpjzxRWbAw== X-Received: by 10.200.56.118 with SMTP id r51mr12409209qtb.120.1477671636501; Fri, 28 Oct 2016 09:20:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.149.168 with HTTP; Fri, 28 Oct 2016 09:20:35 -0700 (PDT) In-Reply-To: References: <20161017155133.A9B8711C257@oc8523832656.ibm.com> From: Yao Qi Date: Fri, 28 Oct 2016 16:20:00 -0000 Message-ID: Subject: Re: [RFC 2/3] Record function descriptor address instead of function address in value To: "Maciej W. Rozycki" Cc: Ulrich Weigand , "gdb-patches@sourceware.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2016-10/txt/msg00816.txt.bz2 On Tue, Oct 18, 2016 at 3:27 AM, Maciej W. Rozycki wrote: > > Agreed. I'd keep `disass main+4,+4' and `x/i main' (or `x/x main', etc., > for that matter) as they are now and consistent with `disass main', if > possible. These would indeed have to be special as we don't actually want > to see the ISA bit set in instruction addresses in disassembly either, as > they are interpreted as memory data rather than execution addresses there. > > For descriptor access, which may undoubtedly be useful sometimes I'd > suggest using `disass &main+4,+4' and `x/i &main', which would be > consistent with the interpretation of function pointers elsewhere (of > course `p main' and `p &main' would roughly be equivalent). Thoughts? Right, "main" in "x/i main" means the function address of main; "&main" means the pointer to function main. However, I am not sure "p main" and "p &main" is equivalent in terms of output. > > Overall I like the proposal and if this goes forward I will see if we can > adapt the MIPS backend to use this approach as well, addressing the issues > we still have remaining, such as confusing instruction addresses and wrong > instruction data shown with `disass /r'. We have a little complication in > that we have the ISA bit set in line information, so that would have to be > stripped in DWARF record processing, but it should be much easier to do > with a single hook in place than the complicated processing now required > to copy ISA bit annotation from the symbol table (msymbols), the hooks to > handle which we'll then be able to drop from our DWARF machinery. > At the very beginning, I wanted to follow the MIPS approach in ARM, but I realized some issues when writing the patch. Then, I switched to the approach I am proposing in this thread. If the ISA bit plus function address is regarded as a function descriptor, this approach should be able to handle all of them (ppc64, arm and mips) correctly (and cleanly, I hope). --=20 Yao (=E9=BD=90=E5=B0=A7)