From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 96626 invoked by alias); 28 Oct 2016 18:41:32 -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 96554 invoked by uid 89); 28 Oct 2016 18:41:26 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,KAM_STOCKGEN,RCVD_IN_DNSWL_LOW,RCVD_IN_SEMBACKSCATTER,SPF_PASS autolearn=ham version=3.3.2 spammy=recursing, huh X-HELO: mx0a-001b2d01.pphosted.com Received: from mx0b-001b2d01.pphosted.com (HELO mx0a-001b2d01.pphosted.com) (148.163.158.5) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 28 Oct 2016 18:41:25 +0000 Received: from pps.filterd (m0098414.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u9SIdCrs014593 for ; Fri, 28 Oct 2016 14:41:23 -0400 Received: from e06smtp10.uk.ibm.com (e06smtp10.uk.ibm.com [195.75.94.106]) by mx0b-001b2d01.pphosted.com with ESMTP id 26cbx08xf3-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Fri, 28 Oct 2016 14:41:23 -0400 Received: from localhost by e06smtp10.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 28 Oct 2016 19:41:21 +0100 Received: from d06dlp01.portsmouth.uk.ibm.com (9.149.20.13) by e06smtp10.uk.ibm.com (192.168.101.140) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Fri, 28 Oct 2016 19:41:20 +0100 Received: from b06cxnps3075.portsmouth.uk.ibm.com (d06relay10.portsmouth.uk.ibm.com [9.149.109.195]) by d06dlp01.portsmouth.uk.ibm.com (Postfix) with ESMTP id 90C9217D8024 for ; Fri, 28 Oct 2016 19:43:35 +0100 (BST) Received: from d06av03.portsmouth.uk.ibm.com (d06av03.portsmouth.uk.ibm.com [9.149.37.213]) by b06cxnps3075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id u9SIfJ3B41615548 for ; Fri, 28 Oct 2016 18:41:19 GMT Received: from d06av03.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av03.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id u9SIfJuM030070 for ; Fri, 28 Oct 2016 12:41:19 -0600 Received: from oc8523832656.ibm.com (icon-9-164-186-41.megacenter.de.ibm.com [9.164.186.41]) by d06av03.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id u9SIfIG5030067; Fri, 28 Oct 2016 12:41:19 -0600 Received: by oc8523832656.ibm.com (Postfix, from userid 500) id EE80810B927; Fri, 28 Oct 2016 20:41:17 +0200 (CEST) Subject: Re: [RFC 2/3] Record function descriptor address instead of function address in value To: qiyaoltc@gmail.com (Yao Qi) Date: Fri, 28 Oct 2016 18:41:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org (gdb-patches@sourceware.org) In-Reply-To: from "Yao Qi" at Oct 28, 2016 05:09:57 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16102818-0040-0000-0000-0000024FB5C9 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 16102818-0041-0000-0000-0000225B8022 Message-Id: <20161028184117.EE80810B927@oc8523832656.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-10-28_11:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609300000 definitions=main-1610280315 X-SW-Source: 2016-10/txt/msg00821.txt.bz2 Yao Qi wrote: > On Mon, Oct 17, 2016 at 4:51 PM, Ulrich Weigand wrote: > > ... and therefore this function cannot really be implemented on ppc64 > > in a fully-general way. In particular, when running stripped binaries > > or code that is otherwise without symbols (e.g. JITted code etc.), this > > conversion may not be possible. > > I don't expect convert_from_func_addr working in general, due to the > reasons you mentioned. convert_from_func_addr is only used when > symbol (from debug information) is available. If we want to GDB > handle such complex expression evaluation correctly, debug > information is required. OK, that makes sense. If we have a symbol from debug information, we probably should also have the msymbol. > > B.t.w. note that there is already a similar function that attempts this > > conversion (ppc-sysv-tdep.c:convert_code_addr_to_desc_addr), but it is > > currently only used during inferior function calls, so it is not so > > critical if it fails. (With your change, that function may actually > > no longer be necessary at that place since values should already point > > to function descriptors ...) > > > > Yes, convert_from_func_addr is similar to convert_code_addr_to_desc_addr. > I removed convert_code_addr_to_desc_addr, but it breaks ifunc > inferior call in my experiment, because ifunc resolver gets the function > address rather than function descriptor address, we still need > convert_code_addr_to_desc_addr to get function descriptor address. Huh? The ifunc resolver is supposed to return a function pointer, which will be a descriptor address on ppc64. Aha, it seems the problem is in GDB's implementaton of elf_gnu_ifunc_resolve_addr, which calls gdbarch_convert_from_func_ptr_addr -- it really shouldn't do this, we should keep descriptors as long as possible. > > Your code already *mostly* does that, with the exception of symbol > > addresses. I'm wondering whether we shouldn't push the change one > > step further back and already store descriptor addresses in > > SYMBOL_VALUE_ADDRESS. Note that this is currently already handled > > somewhat inconsistenly on ppc64: msymbols already point to the > > descriptor, and so do symbols read from stabs debug info; only > > symbols read from DWARF debug info actually point to the code > > address. > > I tried what you suggested, but failed. SYMBOL_VALUE_ADDRESS > is used to get variable address, rather than function's address. We > get function address from block (BLOCK_START), and get block > from symbol (SYMBOL_BLOCK_VALUE). There is no good way to > store function descriptor address in symbol. OK, I see. Doing the conversion when looking up the symbol address should be fine, then. > How about doing this in a followup patch as an enhancement? My > priority is to get this RFC acceptable, and make PPC64/ARM/MIPS > works well. Propagate descriptor address and bug fixes can be done > later. Sure. > > Those are a bit annoying. I think the underlying problem is that operati= > ons > > like "disass" or "x/i" really don't work on "values" in the original sense > > but rather on "PC addresses". Maybe it would make sense to have those > > function enable a special "mode" in the expression evaluator that would > > change the conversion of functions to function pointers to use the code > > address instead of the descriptor address? > > > > I think about the special "mode" in the expression evaluation, but I > suspect that there is a case in a single expression, function address > is expected in some symbol, and descriptor address is expected in > some other symbol, like, > > int func (int i) { return i;} > > (gdb) x/i func + func (1) > > the "func" is expected to be function address and the second "func" > is expected to be function descriptor address. I had a heuristics that > VALUE means function address if we do a pointer add with long type > (valarith.c:value_ptradd). It works fine. I see. This is a bit odd in that evaluating "main" would then return a descriptor while "main + 1" would return a code address, which means the caller is never really sure which one it gets. I think the problem you describe above could still be made to work with the special evalution mode, you'd just have to reset the mode to the default when recursing into certain expression nodes, like e.g. when evaluating the function operand of a OP_FUNCALL node. Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain Ulrich.Weigand@de.ibm.com