From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3722 invoked by alias); 17 Oct 2016 15:51:42 -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 3702 invoked by uid 89); 17 Oct 2016 15:51:42 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.3 required=5.0 tests=AWL,BAYES_00,KAM_STOCKGEN,RCVD_IN_DNSWL_LOW,RCVD_IN_SEMBACKSCATTER,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=AFTER, UD:w, 2001-11, 200111 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; Mon, 17 Oct 2016 15:51:40 +0000 Received: from pps.filterd (m0098417.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u9HFmlcn092138 for ; Mon, 17 Oct 2016 11:51:38 -0400 Received: from e06smtp06.uk.ibm.com (e06smtp06.uk.ibm.com [195.75.94.102]) by mx0a-001b2d01.pphosted.com with ESMTP id 264wb6xb6c-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Mon, 17 Oct 2016 11:51:38 -0400 Received: from localhost by e06smtp06.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 17 Oct 2016 16:51:36 +0100 Received: from d06dlp01.portsmouth.uk.ibm.com (9.149.20.13) by e06smtp06.uk.ibm.com (192.168.101.136) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Mon, 17 Oct 2016 16:51:35 +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 B19A917D805F for ; Mon, 17 Oct 2016 16:53:45 +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 u9HFpYs627918448 for ; Mon, 17 Oct 2016 15:51:34 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 u9HFpYgb005362 for ; Mon, 17 Oct 2016 09:51:34 -0600 Received: from oc8523832656.ibm.com (dyn-9-152-213-118.boeblingen.de.ibm.com [9.152.213.118]) by d06av03.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id u9HFpXev005345; Mon, 17 Oct 2016 09:51:33 -0600 Received: by oc8523832656.ibm.com (Postfix, from userid 500) id A9B8711C257; Mon, 17 Oct 2016 17:51:33 +0200 (CEST) Subject: Re: [RFC 2/3] Record function descriptor address instead of function address in value To: qiyaoltc@gmail.com (Yao Qi) Date: Mon, 17 Oct 2016 15:51:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org In-Reply-To: <1476442387-17291-3-git-send-email-yao.qi@linaro.org> from "Yao Qi" at Oct 14, 2016 11:53:06 AM 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: 16101715-0024-0000-0000-00000234E4F3 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 16101715-0025-0000-0000-000020D0ABA3 Message-Id: <20161017155133.A9B8711C257@oc8523832656.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-10-17_07:,, 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-1610170276 X-SW-Source: 2016-10/txt/msg00485.txt.bz2 Yao Qi wrote: > GCC vs GDB divergence on the meaning of "incr" brings the confusion. > We should reduce such divergence as much as we can. However, this > divergence was added in https://sourceware.org/ml/gdb-patches/2001-11/msg00001.html > I agree with Jim, but I'd like use function descriptor address in value, > which makes the whole expression evaluation look more reasonable and > more close to compiler's behavior. I agree that this is a problem. However, the reasons Jim mentions in that long comment are still valid: it is in general *not possible* to convert an arbitrary function address back to a function descriptor ... > In this patch, I add a new gdbarch method convert_from_func_addr, which > converts function address back to function descriptor address or > function pointer address. It is the reversed operation of > convert_from_func_ptr_addr. ... 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. 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 ...) Note that this checks for presence of an msymbol at the code address, while your code checks for presence of a symbol. Maybe the best way would be to check for either. > We convert function address to function > descriptor address when, > > - we create value for a function, > - we generate ax code for a function, Since the conversion is problematic in general, I think the best way would be to keep descriptor addresses wherever possible, and only convert to code addresses at the last minute when necessary. 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 don't change the meaning of return value of value_as_address, because > it is widely used, so value_as_address still return the function > address if type is TYPE_CODE_FUNC or TYPE_CODE_METHOD. I'm wondering whether this is a good idea; maybe it would be better to return descriptor addresses and update those callers that actually need code addresses. This would keep the principle that we should keep descriptor addresses as long as possible. Also, this might actually fix more bugs; if you look at e.g. this code in value_equal: else if (code1 == TYPE_CODE_PTR && is_int2) return value_as_address (arg1) == (CORE_ADDR) value_as_long (arg2); else if (code2 == TYPE_CODE_PTR && is_int1) return (CORE_ADDR) value_as_long (arg1) == value_as_address (arg2); this might actually cause invalid evaluation of expressions like incr == 0x12345678 (as compared to the native C evaluation). > This patch brings several user visible changes, which look more > accurate, shown by this table below, > > COMMAND BEFORE AFTER > p main main function address main function descriptor > address > disass main disassembly function main not changed > disass main+4,+4 disassembly 4 bytes from disassembly 4 bytes from > function main address + 4 main's function descriptor + 4 > x/i main show one instruction on show one instruction on main's > function main address function descriptor > > Although the latter looks inconvenient, that is consistent to the > meaning on C language level. Due to these changes, test cases are > adjusted accordingly. Those are a bit annoying. I think the underlying problem is that operations 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? Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain Ulrich.Weigand@de.ibm.com