[RFA] Handle DW_OP_form_tls_address

Pedro Alves palves@redhat.com
Fri Sep 2 10:46:00 GMT 2016


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



More information about the Gdb-patches mailing list