From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id JB5YGB15iWDZKAAAWB0awg (envelope-from ) for ; Wed, 28 Apr 2021 11:02:53 -0400 Received: by simark.ca (Postfix, from userid 112) id 569AF1F11C; Wed, 28 Apr 2021 11:02:53 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,MSGID_FROM_MTA_HEADER,RDNS_DYNAMIC, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 4E5191E01F for ; Wed, 28 Apr 2021 11:02:52 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 836623AA1410; Wed, 28 Apr 2021 15:02:51 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 836623AA1410 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1619622171; bh=xovpAxg708RIM7Tougyum54Ra2s99xRhiuFzibpp290=; h=Subject:To:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=hAq8Lq+0BQ+rg6WYsbaETtpVmn+gVp8fktxeqJ0Ga0u/JZopw4x/U9AMAmmQ4aeKO InWFch796hmg8fCxbRIDKaUY+AZK15Zsa1rnycDL/SgCRchamhXO3CQcq8JDoqL/5j 2WNUdb2RbQUPX48YuvR7XEp7sWsUJmW2sjJCnKyk= Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11on2073.outbound.protection.outlook.com [40.107.220.73]) by sourceware.org (Postfix) with ESMTPS id F0F333970806 for ; Wed, 28 Apr 2021 15:02:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org F0F333970806 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gjebGZPG1QRGaI7WgzT8cLt51WBKBgkWgnmVwMj0Z+Uo/mogU+HYaDWrMSMyNLKudV7OljBzgOJ90bKhobsLODY+7emzhLXlyNOFK4XpeDTdiqG/hIlpBo7tBVj/1gUaj/kgSBmAtjeIeCQMKyB8D7rIYiQQxFJ7FKkRmeIO3ni+K6DVjVwyG70Au+V4a7EfWK3mgonc55T9BgUQQn9e46pkGkV+MyvHh5N3MEDniTnPiGRHN7TE73qTpeOynq85sbZeNYX/293pqY+SIc5DqRX+38C258KR6cB0cPyZK/NXwkfEC4b/nRAOXHbSXMM8z+haVZEHqaIzCjF0eWroiw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xovpAxg708RIM7Tougyum54Ra2s99xRhiuFzibpp290=; b=ajh86yjLw/P789lBJ1b+uTcD2yuojaqj7p3rAz+v1nfE2OxqcE4mjtD+tjOGlP58gD04uq0MGT9dcxTuCDWTog2Hsj508/sFzRSlngWLEXt9dBW51OVj5hFle8KmuBpi/yjJ/svdnrfBq8A9AE7dYaWrXnLjpg2NSRt+ZhWiRLyrRrZZ0TufMiKaZE/zPBmmS1mKKRhEQ3kJgjpsARckn6Ald7eRRGGT1+d9hTHeQ4lJz3rQe4Sh6N4SvxNylQx3Hikxl5ToozOfBUBXu0Yf3pFatyJX2wVPcnsI1TFvwPWI6wdgfaKxAtw0UeJP8jviSvNSDkKaVbZQIAj+lYzWzA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass header.d=amd.com; arc=none Received: from DM6PR12MB2762.namprd12.prod.outlook.com (2603:10b6:5:45::15) by DM5PR12MB1371.namprd12.prod.outlook.com (2603:10b6:3:78::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4065.25; Wed, 28 Apr 2021 15:02:46 +0000 Received: from DM6PR12MB2762.namprd12.prod.outlook.com ([fe80::49d0:1ee5:47ef:e0e5]) by DM6PR12MB2762.namprd12.prod.outlook.com ([fe80::49d0:1ee5:47ef:e0e5%7]) with mapi id 15.20.4065.023; Wed, 28 Apr 2021 15:02:46 +0000 Subject: Re: [PATCH 01/43] Replace the symbol needs evaluator with a parser To: Simon Marchi , gdb-patches@sourceware.org References: <20210301144620.103016-1-Zoran.Zaric@amd.com> <20210301144620.103016-2-Zoran.Zaric@amd.com> <33656bad-0e3c-95eb-1dcf-5357cf861422@amd.com> Message-ID: <516d9253-146a-0bab-e548-f795ab9729bd@amd.com> Date: Wed, 28 Apr 2021 16:02:42 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.9.1 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [2a00:23c7:5a85:6801:f5b0:44e8:2b3e:76c1] X-ClientProxiedBy: LO4P123CA0070.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:153::21) To DM6PR12MB2762.namprd12.prod.outlook.com (2603:10b6:5:45::15) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [IPv6:2a00:23c7:5a85:6801:f5b0:44e8:2b3e:76c1] (2a00:23c7:5a85:6801:f5b0:44e8:2b3e:76c1) by LO4P123CA0070.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:153::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4065.25 via Frontend Transport; Wed, 28 Apr 2021 15:02:45 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 619af03e-560e-49e6-a39a-08d90a56ae54 X-MS-TrafficTypeDiagnostic: DM5PR12MB1371: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: dXklvcLfz9/8kTvehkxnRzOIgai2IE3us3F9681zn+yi55FCMib1azdrhcIKbLxz5CvAqrJt/rFTe+C88pyslBFyvrjNKjN1+ugy4J/mMUXw5sO4I/NXeCrMWjrQrMLUdg7D8RsNwdxyGi7Urd13piN+VRzSb3L3LCljba7S2qQLioC4y1LOQzG1k1GrPAfD01eeXKHnL2tj88szn786NpgEvYgRS9WaF8DNoV3GXu/TL/DOQlQEM1+PLd7H41IjIZWx173nyTpdVOef+gvncIpXujuMNrkPwij8tWqTYzmOeCWzCZPdjEujxc3mUzOSiWSkRbcd/I3R+s9nmXK2bq2u5PPUS03OL/oYWIcBI2/T8qVMdLXuyh4yzP94Ax6lSa+6PVH/h5RV8zGdTztUR3xr5sXeyycctH+W+9npbyO101QwnPES6b610dQB1BTf1JkzhhnlqTCb+2Wksq4ESTklleR4V72QdqoFD8pDu+3Bttqi2e2O5fWXOx84chmIb7wQ7EodYdYpx7V9sYTPIlwkzdBzyBmXPXg9zl9oSvuPwUC78gkt/LNLYxeHEON9bO/QyqcVQt9ZB4yEaBpVFqRQQJKvaQzUMTyRBobUwP4VZ2KQN3c43dOts2nlSH7mYUARFmzDcsCZXiiSGLpKmbuSMG7C0Yb/toTyhJ362mmU7RH9+7FTIRYTBgP0bVgc X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR12MB2762.namprd12.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(39860400002)(366004)(396003)(376002)(346002)(2616005)(31686004)(186003)(316002)(83380400001)(36756003)(2906002)(478600001)(8936002)(6666004)(31696002)(86362001)(6486002)(16526019)(66556008)(66476007)(38100700002)(5660300002)(52116002)(8676002)(66946007)(43740500002)(45980500001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?Z3M1ckNXaXVLR0l4a2NEODJxRXRzdExXV282MnVBSGdqRVYzL21sK2pQS2Js?= =?utf-8?B?NnpVLyt5TU9mbU5iMHFoSU9Ya2ZNUFQraXo1alFRd3FnTlYyYzg5VmZTMEtn?= =?utf-8?B?UHBXUU1XTmdBOStWZjFMVWVHVUZKOW04TS9mQmhESmdoUzJRMzBlaW1jUlg1?= =?utf-8?B?cFMyeDZBNW1hTkQweDlaM0srY3JPMUQrTU1HQW5Ea3hkLzd1RFphdmNTQmkz?= =?utf-8?B?NmIzcWNpeHo3RjBVck9MMm5PRUhUci9UN29rc2JOeUNxVGdabFYwS1lVVU1W?= =?utf-8?B?ZGk1bjMxNWQ4RTd2V3M3d2p0d2ZZZGhWZHFNY0sxczAwNkJCNG5hbHJuaCsv?= =?utf-8?B?VjVlVCtaTVpXR0JlY1oyRlNXNzFFSkVNV0VWNVNRVUJSa0JOcysxSVE4WWtm?= =?utf-8?B?elhVSFJualFGeE9Ka1grSlFqZVJmazFIU0FhY2cxQ2FwZDZxeTFaejNKNzYx?= =?utf-8?B?VEJRRXZUWmdMdk1BNThjaWhmc1Zpdk1zOUE2ZUdKRkcxY3hDcVEyMHNCNmxx?= =?utf-8?B?bzJPeGJHSXhXL3NaMmptT0ttUGRYUkkwZDhXenRteXJqWTlpblcwT1IyeGx0?= =?utf-8?B?NHgvL3RINlVSSlhqeHlQc25pT0M1anlJVmdRWWJtRS9TaUJyMXFwY3pxbDkv?= =?utf-8?B?dy9ITUR5eXd4ek1neElzYk9hUDMxY0JrQTYrNE1FcGxxaFJHQ3JsYTZGSktp?= =?utf-8?B?dmpuV3d5Z0hFUWlCVXhNNVNGRm1kSDhQRkF4OWdNOVdEN25BaDJ5dmZ2WWtT?= =?utf-8?B?TnY3WVZMQ05Xc1ZybUlCTTJpc3VHeEpGamp3R2JIbHZpd2xacXZoSmg0Y3A0?= =?utf-8?B?czhnYW9YbU05Y1F1V2Q3NVgySFBsZUVuUjg0ZVVlWEpnWlNRZVkzRFh5MDgx?= =?utf-8?B?dFVLNkZMcnQ1Lzg5OEpXVk9Vem8yZ2x4TEFiN2h1MmtoMGhCa2dSQ0w1MVlT?= =?utf-8?B?YWY1NW9QY0tVZzc0VktpMG1LWUhZVGl3QlFSNU9IRE01ZTdpMjdUZUJvQ0t1?= =?utf-8?B?d1RvU1I0SjJmbGRHeTR4ODF5QWlhYmFsZGFRMW9rS3BXak9SODhpc3prRWkx?= =?utf-8?B?STFpTGp1K1hxTXpTMFBtQ1p3RWtEK0pnOStLS0cxcWtCWU5PT3FVbjRCWER0?= =?utf-8?B?bWtDaFk3dHVVWXNPWGxYNjdLekxSSmZXbjNZL1V2NjRlc25COTMzc1dzVkdD?= =?utf-8?B?RlVXTlNsYlJjTm14R2JoSGJLMnZyQ09iTXlOTmNtSHdCcjVTVDFYR2FOT3dS?= =?utf-8?B?WS9qejc2NSthTEpQRmF6Y2M2alEyc1JlTVorcjFpWExiVDlBS1NiRlRVUXZC?= =?utf-8?B?Qjc5bk83WFBtTUN2Nk9ZUHFoYmplSG9NbjVEbjhXQkVsVG1OQmlxeXNvbVpO?= =?utf-8?B?bUxiY3RNRzljUTB3eEQ2NnN2QmxydEtLa2JpRzRlVGt3MXpFSUppZWVwYm1i?= =?utf-8?B?UllhYmZPYmp2QW02bW5YNklSQ2pjcWhadi9RNERCQTRBQStDVWRWZXkvd1Qr?= =?utf-8?B?cW8zejdNVEt4WkZ4dVJGTXRrcEY5bTNKTlBWV0FvTG9NeTVSeXpDK2Jray9W?= =?utf-8?B?SitiOUJ2UUJuQ2pYb09VYVRNaWRjQTdDS3YxNFdIdDhtaW0ySDBiY2dzZTFk?= =?utf-8?B?OTJxc2hGVkRkeFRIaGNabEpMbEU2SklMNGVaZHljY2VUYVBVL0JnUFVZdFA2?= =?utf-8?B?dHZvYTNyUWkxcDlsU1NqNDJzdCtqVlF4ei8vNnZ4VTcwM1RCZnJWVHMrdFlr?= =?utf-8?B?SklFUTB1d01sQkwrYzBWVU15UkFHTnRWL2FqKzZvVzdJSEo3Y2RyQld1NlBN?= =?utf-8?B?TGw2T1diZHNUd1hDcVA3bFdrd3lxQ3M4dFFZZkhGcmtqLzJLV3Nib1Zxdkp2?= =?utf-8?Q?zZmwaJUtiaMsy?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: 619af03e-560e-49e6-a39a-08d90a56ae54 X-MS-Exchange-CrossTenant-AuthSource: DM6PR12MB2762.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Apr 2021 15:02:45.9842 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: YJJdFWjLsf116cJL99uMLuSpcHbQafgtdIrHUYDzMnGhqGuMHEsdm1TrLmeX15AXYVi92pgizRY4IV8+vCwKKg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR12MB1371 X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Zoran Zaric via Gdb-patches Reply-To: Zoran Zaric Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" >>>> Some concerns were raised that a linear scan of the expression byte >>>> stream would have issues if a DWARF producer would try to hide some >>>> non DWARF related data after a control flow operation. Although the >>>> testsuite doesn't show this case, it is a valid concern, so one of >>>> the later patches in this series will address it by switching back to >>>> the then redesigned DWARF expression evaluator. >>> >>> While re-reading your exchange with Tom, I was under the impression that >>> traversing the "control flow graph" of the expression, visiting each >>> node only once, would be a good solution. It would avoid the infinite >>> loop problem, the "two branches" problem, and even the corner cases >>> where you have garbage in the middle of the expression, or if the >>> expression jumps in the middle of an instruction to re-use the operand >>> of an instruction as an instruction. >>> >>> Patch 39 changes this back to an evaluator, so I'm not sure if this is >>> what you implemented or something else, I'll see when I get there. >> >> There is no concept of a "control flow graph" in the existing gdb evaluator, there is just a byte stream that gdb either fully traverse and evaluates or it "fakes" the target access. > > When I meant "control flow graph", I didn't mean to have a proper > control flow graph representation with classes and all (unless we think > it would be useful), but just navigate it conceptually. > > You maintain a queue of "to visit" instructions and a set of "already > visited" instructions. You by pushing the first instruction in the > queue and work until the queue is empty. For all instructions but > conditional jumps, you push the instruction after it in the queue. For > conditional jumps, you also push the jump target in the queue. You > maintain the "already visited" set on the side to avoid visiting the > same instruction twice, in case there are loops. Right, this would probably work, but the only problem it is solving is the garbage issue, and considering that the later patch in the series removes this temporary solution anyway. I don't think it is worth the time in re-implementing it. > >> >> The solution that Tom talked about was just an idea that he used in some other tool and would need to be implemented from scratch. >> >> The patch 39 switches the evaluator design to throwing the missing context exception idea which re-enables using the same evaluator for both purposes. > > I'll see and understand better when I get there. But from what I > understood of past dicussions, using the evaluator may give wrong > results, because one branch may require only registers while another > branch may require a frame (that's the point of your patch). So I don't > really understand how going back to using an evaluator would work. You can't really have a register without a frame. That doesn't really make sense in any of the existing targets. Even the struct value describing the register location always needs to have a frame defined. The question that symbol needs is answering is if the symbol needs a frame or not. And this is why catching an exception thrown by the evaluator when the frame was needed but missing does work. > > Although that depends on the semantic we want symbol_needs to have: > > - find what's needed to evaluate the expression in the current context, > only in the branch that would be taken right now? > - find what's needed to evaluate the expression in any possible > context, considering all branches? > > Simon > Symbol needs is always called regarding the current context, I didn't see anything that proves otherwise. Zoran