[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gdb-patches
Subject:    [PATCH] Support for DWARF5 location lists entries
From:       simark () simark ! ca (Simon Marchi)
Date:       2019-12-31 18:33:00
Message-ID: 48103fb5-d3ee-0ae0-92a7-f1c02debd449 () simark ! ca
[Download RAW message or body]

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


[prev in list] [next in list] [prev in thread] [next in thread]