From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 55529 invoked by alias); 31 Dec 2019 18:33:28 -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 55517 invoked by uid 89); 31 Dec 2019 18:33:27 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: =?ISO-8859-1?Q?No, score=-5.4 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 spammy=8:=c2=b7, if, 8:le, 8:en?= X-HELO: simark.ca Received: from simark.ca (HELO simark.ca) (158.69.221.121) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 31 Dec 2019 18:33:26 +0000 Received: from [10.0.0.11] (unknown [192.222.164.54]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id D90DA1E50B; Tue, 31 Dec 2019 13:33:24 -0500 (EST) Subject: Re: [PATCH] Support for DWARF5 location lists entries To: "Achra, Nitika" , "gdb-patches@sourceware.org" Cc: "George, Jini Susan" , Ali Tamur References: From: Simon Marchi Message-ID: <48103fb5-d3ee-0ae0-92a7-f1c02debd449@simark.ca> Date: Tue, 31 Dec 2019 18:33:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-SW-Source: 2019-12/txt/msg01088.txt.bz2 On 2019-12-31 4:41 a.m., Achra, Nitika wrote: > [AMD Official Use Only - Internal Distribution Only] > > > > * Handle DW_LLE_base_addressx, DW_LLE_startx_length and DW_LLE_start_length. > > > > Tested by running the testsuite before and after the patch and there is no increase in the number of test cases that fails. > > Tested with both -gdwarf-4 and -gdwarf-5 flags. > > > > > gdb/ChangeLog: > *gdb/dwarf2loc.c (decode_debug_loclists_addresses): Handle DW_LLE_base_addressx, DW_LLE_startx_length, DW_LLE_start_length. Hi Nitika, Thanks for the patch. I don't have time to do an in-depth review right now, but I just wanted to point out the common formatting quirks of the GNU style, so you can apply it to this patch. In terms of indentation, we use two columns for each indent. However, leading groups of 8 spaces get converted to a tab. So instead of 14 spaces, you would have one tab followed by 6 spaces to reach the desired column. Most editors have a way to be set up like this. Unfortunately, VSCode can't. We use a space before opening parenthesis in function declaration/definitions/calls. So: loc_ptr·=·gdb_read_uleb128(loc_ptr,·buf_end,·&u64); would become loc_ptr·=·gdb_read_uleb128 (loc_ptr,·buf_end,·&u64); This: if·(loc_ptr·==·NULL) return·DEBUG_LOC_BUFFER_OVERFLOW; should become: if·(loc_ptr·==·NULL) return·DEBUG_LOC_BUFFER_OVERFLOW; Simon