Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Simon Marchi <simon.marchi@polymtl.ca>
To: Andreas Arnez <arnez@linux.vnet.ibm.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH 3/9] PR gdb/21226: Take DWARF stack value pieces from LSB  end
Date: Fri, 14 Apr 2017 03:36:00 -0000	[thread overview]
Message-ID: <0144cae486cd82860db324db6f2e1e1e@polymtl.ca> (raw)
In-Reply-To: <1491586736-21296-4-git-send-email-arnez@linux.vnet.ibm.com>

On 2017-04-07 13:38, Andreas Arnez wrote:
> When taking a DW_OP_piece or DW_OP_bit_piece from a DW_OP_stack_value, 
> the
> existing logic always takes the piece from the lowest-addressed end, 
> which
> is wrong on big-endian targets.

I'd like if you could clarify this (just here not necessarily in the 
patch).  DWARF locations are computed inside GDB, on the host.  So does 
it really depend on the target endianness, or it's that of the host, or 
both?

Let's consider these cases of remote debugging:

  host -> target
  x86  -> x86
  x86  -> s390
  s390 -> x86
  s390 -> s390

In which cases is the value found at the high memory address vs low 
memory address?

> The DWARF standard states that the
> "DW_OP_bit_piece operation describes a sequence of bits using the least
> significant bits of that value", and this also matches the current 
> logic
> in GCC.  For instance, the GCC guality test case pr54970.c fails on 
> s390x
> because of this.
> 
> This fix adjusts the piece accordingly on big-endian targets.  It is
> assumed that:
> 
> * DW_OP_piece shall take the piece from the LSB end as well;
> 
> * pieces reaching outside the stack value bits are considered 
> undefined,
>   and a zero value can be used instead.
> 
> gdb/ChangeLog:
> 
> 	PR gdb/21226
> 	* dwarf2loc.c (read_pieced_value): Anchor stack value pieces at
> 	the LSB end, independent of endianness.
> 
> gdb/testsuite/ChangeLog:
> 
> 	PR gdb/21226
> 	* gdb.dwarf2/nonvar-access.exp: Add checks for verifying that
> 	stack value pieces are taken from the LSB end.
> ---
>  gdb/dwarf2loc.c                            | 43 
> ++++++++++++++++--------------
>  gdb/testsuite/gdb.dwarf2/nonvar-access.exp | 21 ++++++++++++---
>  2 files changed, 41 insertions(+), 23 deletions(-)
> 
> diff --git a/gdb/dwarf2loc.c b/gdb/dwarf2loc.c
> index 496400a..09938c4 100644
> --- a/gdb/dwarf2loc.c
> +++ b/gdb/dwarf2loc.c
> @@ -1857,6 +1857,10 @@ read_pieced_value (struct value *v)
>  		if (unavail)
>  		  mark_value_bits_unavailable (v, offset, this_size_bits);
>  	      }
> +
> +	    copy_bitwise (contents, dest_offset_bits,
> +			  intermediate_buffer, source_offset_bits % 8,
> +			  this_size_bits, bits_big_endian);
>  	  }
>  	  break;
> 
> @@ -1865,26 +1869,28 @@ read_pieced_value (struct value *v)
>  			     p->v.mem.in_stack_memory,
>  			     p->v.mem.addr + source_offset,
>  			     buffer.data (), this_size);
> +	  copy_bitwise (contents, dest_offset_bits,
> +			intermediate_buffer, source_offset_bits % 8,
> +			this_size_bits, bits_big_endian);
>  	  break;
> 
>  	case DWARF_VALUE_STACK:
>  	  {
> -	    size_t n = this_size;
> +	    struct objfile *objfile = dwarf2_per_cu_objfile (c->per_cu);
> +	    struct gdbarch *objfile_gdbarch = get_objfile_arch (objfile);
> +	    ULONGEST obj_size = 8 * TYPE_LENGTH (value_type (p->v.value));

It would be really nice for the readers if you could put some comment 
like this, even though it may seem obvious to you:

   /* The size of a DWARF stack value.  */
   ULONGEST obj_size = 8 * TYPE_LENGTH (value_type (p->v.value));

I found I had to add them to the code to be able to follow.

> 
> -	    if (n > c->addr_size - source_offset)
> -	      n = (c->addr_size >= source_offset
> -		   ? c->addr_size - source_offset
> -		   : 0);
> -	    if (n == 0)
> -	      {
> -		/* Nothing.  */
> -	      }
> -	    else
> -	      {
> -		const gdb_byte *val_bytes = value_contents_all (p->v.value);

> +	    /* Use zeroes if piece reaches beyond stack value.  */
> +	    if (p->size > obj_size)
> +	      break;

Does this happen, for example, if a DWARF stack value is 32 bits long, 
but the piece is 64 bits?  I suppose that's not something we'd want a 
compiler to emit, and would be considered a bug in the compiler?

How does breaking out of the loop will use zeroes?  Is the value buffer 
cleared beforehand?

> 
> -		intermediate_buffer = val_bytes + source_offset;
> -	      }
> +	    /* Piece is anchored at least significant bit end.  */
> +	    if (gdbarch_byte_order (objfile_gdbarch) == BFD_ENDIAN_BIG)
> +	      source_offset_bits += obj_size - p->size;

Just a nit, but I find it more readable when there's an empty line 
between the if and the following lines not included in the if (so here, 
right where I cut the quote).  It reads like two separate sentences:

  - If the byte order is big endian, adjust offset in the source.
  - Copy bitwise from the source buffer to the destination buffer.

> +	    copy_bitwise (contents, dest_offset_bits,
> +			  value_contents_all (p->v.value),
> +			  source_offset_bits,
> +			  this_size_bits, bits_big_endian);

Thanks,

Simon


  reply	other threads:[~2017-04-14  3:36 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-07 17:39 [PATCH 0/9] Various DWARF piece fixes Andreas Arnez
2017-04-07 17:39 ` [PATCH 1/9] Add test for modifiable DWARF locations Andreas Arnez
2017-04-13  4:00   ` Simon Marchi
2017-04-13 10:52     ` Andreas Arnez
2017-04-13  8:36   ` Yao Qi
2017-04-13 11:46     ` Andreas Arnez
2017-04-07 17:40 ` [PATCH 2/9] Fix size capping in write_pieced_value Andreas Arnez
2017-04-13  8:18   ` Yao Qi
2017-04-13 16:35     ` Andreas Arnez
2017-04-19  9:15       ` Yao Qi
2017-04-19 14:36         ` Andreas Arnez
2017-04-19 15:00           ` Yao Qi
2017-04-07 17:41 ` [PATCH 4/9] Remove addr_size field from struct piece_closure Andreas Arnez
2017-04-13  9:10   ` Yao Qi
2017-04-14  3:39     ` Simon Marchi
2017-04-18 17:25       ` Andreas Arnez
2017-04-18 18:49         ` Simon Marchi
2017-04-07 17:41 ` [PATCH 3/9] PR gdb/21226: Take DWARF stack value pieces from LSB end Andreas Arnez
2017-04-14  3:36   ` Simon Marchi [this message]
2017-04-18 16:32     ` Andreas Arnez
2017-04-18 16:43       ` Simon Marchi
2017-04-07 17:42 ` [PATCH 5/9] Fix issues in write_pieced_value when targeting bit-fields Andreas Arnez
2017-04-14  5:18   ` Simon Marchi
2017-04-27 17:54     ` Andreas Arnez
2017-05-03 13:59       ` Simon Marchi
2017-04-07 17:43 ` [PATCH 7/9] Improve logic for buffer allocation in read/write_pieced_value Andreas Arnez
2017-04-14 14:51   ` Simon Marchi
2017-04-07 17:43 ` [PATCH 6/9] Fix handling of DWARF register pieces on big-endian targets Andreas Arnez
2017-04-14 14:11   ` Simon Marchi
2017-04-19 18:03     ` Andreas Arnez
2017-04-07 17:44 ` [PATCH 8/9] Respect piece offset for DW_OP_bit_piece Andreas Arnez
2017-04-14 15:07   ` Simon Marchi
2017-04-07 17:45 ` [PATCH 9/9] Remove unnecessary copies of variables in read/write_pieced_value Andreas Arnez
2017-04-14 15:21   ` Simon Marchi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0144cae486cd82860db324db6f2e1e1e@polymtl.ca \
    --to=simon.marchi@polymtl.ca \
    --cc=arnez@linux.vnet.ibm.com \
    --cc=gdb-patches@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox