Big-endian targets: Don't ignore offset into DW_OP_implicit_value

When a variable's location is expressed as DW_OP_implicit_value, but the
given value is longer than needed, which bytes should be used?  GDB's
current logic was introduced with a patch from 2011 and uses the "least
significant" bytes:

  https://sourceware.org/ml/gdb-patches/2011-08/msg00123.html

Now consider a sub-value from such a location at a given offset, accessed
through DW_OP_implicit_pointer.  Which bytes should be used for that?  The
patch above *always* uses the last bytes on big-endian targets, ignoring
the offset.

E.g., given the code snippet

  const char foo[] = "Hello, world!";
  const char *a = &foo[0];
  const char *b = &foo[7];

assume that `foo' is described as DW_OP_implicit_value and `a' and `b'
each as DW_OP_implicit_pointer into that value.  Then with current GDB
`*a' and `*b' yield the same result -- the string's zero terminator.

This patch basically reverts the portion of the patch above that deals
with DW_OP_implicit_value.  This fixes the offset handling and also goes
back to dropping the last instead of the first bytes on big-endian targets
if the implicit value is longer than needed.  The latter aspect of the
change probably doesn't matter for actual programs, but simplifies the
logic.

The patch also cleans up the original code a bit and adds appropriate test
cases.

gdb/testsuite/ChangeLog:

	* gdb.dwarf2/dw2-op-stack-value.exp: Adjust expected result of
	taking a 2-byte value out of a 4-byte DWARF implicit value on
	big-endian targets.
	* gdb.dwarf2/nonvar-access.exp: Add more comments to existing
	logic.  Add test cases for DW_OP_implicit.

gdb/ChangeLog:

	* dwarf2loc.c (dwarf2_evaluate_loc_desc_full): For
	DWARF_VALUE_LITERAL, no longer ignore the offset on big-endian
	targets.  And if the implicit value is longer than needed, extract
	the first bytes instead of the "least significant" ones.

0 files changed, 0 insertions, 0 deletions