[RFA] Handle DW_OP_form_tls_address

  Currently gdb supports DW_OP_GNU_push_tls_address, but not
DW_OP_form_tls_address.  I think it would be better if the toolchain
as a whole moved to using the standard opcode, and the prerequisite to
this is getting gdb to recognize it.

GCC can sometimes emit DW_OP_form_tls_address for emultls targets.  As
far as I know, nobody has ever tried this with gdb (since it wouldn't
work at all).

I don't think there's a major drawback to using a single opcode for
all targets, because computing the location of a thread-local is
already target specific.

This is PR gdb/11616.

I don't know how to write a test case for this; though it's worth
noting that there aren't explicit tests for DW_OP_GNU_push_tls_address
either -- and if I change GCC, these paths will be tested to the same
extent they are now.

2016-08-22  Tom Tromey  <tom@tromey.com>

	PR gdb/11616:
	* dwarf2read.c (decode_locdesc): Handle DW_OP_form_tls_address.
	* dwarf2loc.c (dwarf2_compile_expr_to_ax): Handle
	DW_OP_form_tls_address.
	(locexpr_describe_location_piece): Likewise.
	* dwarf2expr.h (struct dwarf_expr_context_funcs): Update comment.
	* dwarf2expr.c (execute_stack_op): Handle DW_OP_form_tls_address.
	(ctx_no_get_tls_address): Mention DW_OP_form_tls_address.
	* compile/compile-loc2c.c (struct insn_info): Update comment.
	(compute_stack_depth_worker): Handle DW_OP_form_tls_address.
---
 gdb/ChangeLog               | 13 +++++++++++++
 gdb/compile/compile-loc2c.c |  7 ++++---
 gdb/dwarf2expr.c            |  3 ++-
 gdb/dwarf2expr.h            |  2 +-
 gdb/dwarf2loc.c             |  7 +++++--
 gdb/dwarf2read.c            |  1 +
 6 files changed, 26 insertions(+), 7 deletions(-)
  

On 08/23/2016 12:04 AM, Tom Tromey wrote:
> Currently gdb supports DW_OP_GNU_push_tls_address, but not
> DW_OP_form_tls_address.  I think it would be better if the toolchain
> as a whole moved to using the standard opcode, and the prerequisite to
> this is getting gdb to recognize it.

Are the semantics of the two exactly the same?

> 
> GCC can sometimes emit DW_OP_form_tls_address for emultls targets.  As
> far as I know, nobody has ever tried this with gdb (since it wouldn't
> work at all).
> 
> I don't think there's a major drawback to using a single opcode for
> all targets, because computing the location of a thread-local is
> already target specific.
> 
> This is PR gdb/11616.
> 
> I don't know how to write a test case for this; though it's worth
> noting that there aren't explicit tests for DW_OP_GNU_push_tls_address
> either -- and if I change GCC, these paths will be tested to the same
> extent they are now.

I suppose that if we wanted to always test both, ideally we'd use
the dwarf assembler to write something simple like '__thread foo = 2;',
and then make sure we can print foo when we get to main.  We'd start out
with one arch, and then tweak the test to support or be skipped on
other tls model variations as people test on other archs.

> 
> 2016-08-22  Tom Tromey  <tom@tromey.com>
> 
> 	PR gdb/11616:
> 	* dwarf2read.c (decode_locdesc): Handle DW_OP_form_tls_address.
> 	* dwarf2loc.c (dwarf2_compile_expr_to_ax): Handle
> 	DW_OP_form_tls_address.
> 	(locexpr_describe_location_piece): Likewise.
> 	* dwarf2expr.h (struct dwarf_expr_context_funcs): Update comment.
> 	* dwarf2expr.c (execute_stack_op): Handle DW_OP_form_tls_address.
> 	(ctx_no_get_tls_address): Mention DW_OP_form_tls_address.
> 	* compile/compile-loc2c.c (struct insn_info): Update comment.
> 	(compute_stack_depth_worker): Handle DW_OP_form_tls_address.

LGTM as is.

Thanks,
Pedro Alves
  

>>>>> "Pedro" == Pedro Alves <palves@redhat.com> writes:

Pedro> On 08/23/2016 12:04 AM, Tom Tromey wrote:
>> Currently gdb supports DW_OP_GNU_push_tls_address, but not
>> DW_OP_form_tls_address.  I think it would be better if the toolchain
>> as a whole moved to using the standard opcode, and the prerequisite to
>> this is getting gdb to recognize it.

Pedro> Are the semantics of the two exactly the same?

Yes, but with a footnote.

DW_OP_form_tls_address is described in the standard:

    The DW_OP_form_tls_address operation pops a value from the stack,
    translates it into an address in the current thread's thread-local
    storage block, and pushes the address. If the DWARF expression
    containing the DW_OP_form_tls_address operation belongs to the main
    executable's DWARF info, the operation uses the main executable's
    thread-local storage block; if the expression belongs to a shared
    library's DWARF info, then it uses that shared library's
    thread-local storage block.

DW_OP_GNU_push_tls_address isn't documented to my knowledge; however it
pops a value from the stack and translates it into an address.

In either case, it seems to me that there's also a lot left to the
implementation, so much so that we can treat them identically.

My theory is that maybe the GNU one was added first and then
standardized.  But I didn't do any archaeology to try to find out for
sure.

Pedro> LGTM as is.

Thanks.

Tom