llvm dev - Jun 2021 - [DWARF] using simplified template names

> (out of curiosity, any idea what the Sony debugger does for
> pointer template parameters? At least GCC doesn't seem to be
> able to reconstruct those back into strings (you'd basically
> have to symbolize the address value of the parameter (GCC
> doesn't even encode this value, so it's not surprising GDB
> doesn't try to do anything when it's present)) - so I'll
> probably implement this under a flag but not include (ie: use
> the current full textual encoding) any template with a pointer
> template parameter)
>
> eg: extern int i; template<int *> void f1() { } int main() {
f1<&i>(); }
Nice catch, we don't do anything clever here either.  This would
appear to be a special case of non-type template params that can
be arbitrary compile-time expressions; for non-pointer params we 
provide the computed value of the compile-time expression, which 
is arguably sufficient for cases like

  constexpr int a = 1; constexpr int b = 2;
  template <int> void f2() { }
  void int_expr() { f2<a + b>(); }

but it would be nice to do something useful for

  extern int j[4];
  void ptr_expr() { f1<&j[a+b]>(); }

We can't repurpose DW_AT_name for this because that's the 
template parameter's formal name; nothing else comes to mind,
maybe we need a new attribute for this.
--paulr

On Wed, Jun 16, 2021 at 11:35 AM <paul.robinson at sony.com> wrote:
> > (out of curiosity, any idea what the Sony debugger does for
> > pointer template parameters? At least GCC doesn't seem to be
> > able to reconstruct those back into strings (you'd basically
> > have to symbolize the address value of the parameter (GCC
> > doesn't even encode this value, so it's not surprising GDB
> > doesn't try to do anything when it's present)) - so I'll
> > probably implement this under a flag but not include (ie: use
> > the current full textual encoding) any template with a pointer
> > template parameter)
> >
> > eg: extern int i; template<int *> void f1() { } int main() {
f1<&i>(); }
>
> Nice catch, we don't do anything clever here either.

Do you do equality on the computed DW_AT_location value to test whether one
DW_TAG_template_value_parameter is equal to another (& so whether the
template instantiation in one CU is the same type as in another CU)?
Probably pretty reliable if you do the comparison with the result of DWARF
expression evaluation.

> This would
> appear to be a special case of non-type template params that can
> be arbitrary compile-time expressions; for non-pointer params we
> provide the computed value of the compile-time expression, which
> is arguably sufficient for cases like
>
>   constexpr int a = 1; constexpr int b = 2;
>   template <int> void f2() { }
>   void int_expr() { f2<a + b>(); }
>
> but it would be nice to do something useful for
>
>   extern int j[4];
>   void ptr_expr() { f1<&j[a+b]>(); }
>
Conveniently this feature is not quite so general, this code would fail to
compile (GCC says, for instance: "'& j[3]' is not a valid
template argument
of type 'int*' because 'j[3]' is not a variable", Clang
just says the
parameter is "invalid")

But passing only 'j' is valid. So in theory we could have some attribute
that points to the variable declaration of 'j' in this case, which could
allow structural equality testing using this DWARF. I'm not sure what
we'd
call that attribute - I guess we could repurpose the DW_AT_location
attribute - if it's a DW_FORM_ref* encoding, it refers to another DIE whose
location is used (this makes me a bit twitchy because it sounds like
DW_OP_implicit_pointer which I think is overly narrow (by describing only
an implicit pointer to another object, rather than to an arbitrary value) -
but in this case at least for now, C++ doesn't support any generalization,
it must point to a named variable so far as I understand), and if it's
DW_FORM_exprloc it's what we do today already.

This might help address the difficult issue that GCC and Clang have split
on - GCC, by not including the DW_AT_location ensures that enabling debug
info doesn't affect codegen/linking. Clang ensures the value is debuggable,
but at the cost of causing the value to be linked into the final binary
even if the production code doesn't use it (due to the relocation in the
DW_AT_location causing the linker to pull in the value). Hmm, actually I
don't really know what the issue is there - clearly we use some kind of
relocation for functions that doesn't have this problem, so maybe we're
just not using the right kind of relocation for variables? Or there's a gap
in relocation support/features that we should fill?

In any case, having DW_AT_location refer to the DW_TAG_variable then the
DW_TAG_variable doesn't necessarily need to have a DW_AT_location (to avoid
the linking issue) & if it has a linkage name, the consumer can look up the
symbol itself to find it without a DW_AT_location.

(
Here's an example of the linkage issue:

$ cat > nttp.cpp

extern int i;

template<int*> void f1() { }

int main() { f1<&i>(); }

$ clang++-tot nttp.cpp -g

/usr/local/google/home/blaikie/install/bin/../lib/gcc/x86_64-pc-linux-gnu/10.0.0/../../../../x86_64-pc-linux-gnu/bin/ld:
/tmp/nttp-e4e14a.o:(.debug_info+0x63): undefined reference to `i'

clang-13: *error: **linker command failed with exit code 1 (use -v to see
invocation)*

$ clang++-tot nttp.cpp

$ g++-tot nttp.cpp

$ g++-tot nttp.cpp -g

$

> We can't repurpose DW_AT_name for this because that's the
> template parameter's formal name; nothing else comes to mind,
> maybe we need a new attribute for this.
> --paulr
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210617/9ecc2edd/attachment.html>