Richard Henderson wrote:
> +@deftypefn {Target Hook} int TARGET_ADDR_SPACE_DEBUG (addr_space_t @var{as})
> +Define this to define how the address space is encoded in dwarf.
> +The result, @var{r}, should be positive to indicate
> +@code{DW_AT_address_class @var{r}} should be emitted; or negative
> +to indicate @code{DW_AT_segment} with location in register @code{~@var{r}}.
> +@end deftypefn
>From my reading of the DWARF specs, DW_AT_segment and DW_AT_address_class
are intended to be used for different purposes:
Any debugging information entry that contains a description of the location
of an object or subroutine may have a DW_AT_segment attribute, whose value
is a location description. The description evaluates to the segment selector
of the item being described.
vs.
Any debugging information entry representing a pointer or reference type or
a subroutine or subroutine type may have a DW_AT_address_class attribute,
whose value is an integer constant. The set of permissible values is specific
to each target architecture.
Back when we implemented address space support for Cell/B.E. I interpreted
this to mean that DW_AT_segment was intended to be used for DIEs *defining*
an object, while DW_AT_address_class was intended to be used for pointer
types. (Since the former wasn't possible on Cell/B.E., we never actually
implemented DW_AT_segment back then.)
B.t.w. Appendix A of the DWARF4 standard also does *not* list DW_AT_segment
as a valid attribute for a DW_TAG_pointer_type or DW_TAG_reference_type DIE.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
