backend: dwarfdbginf: Remove artificial attributes on wchar_t typedef

[ljmf00]

According to DWARF, declaration coordinates are not mandatory and wchar_t is
currently an artificial typedef. We should not generate DECL attributes for
such artificial TAGs.

Signed-off-by: Luís Ferreira contact@lsferreira.net

[dlang-bot]

Thanks for your pull request, @ljmf00!

Bugzilla references

Auto-close	Bugzilla	Severity	Description
✓	22467	normal	DWARF: wchar_t reports wrong DECL attributes

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub run digger -- build "master + dmd#13247"

[Geod24]

Sounds right. I'll have a look at the spec just in case. Got any ref for us ?

[ljmf00]

Sounds right. I'll have a look at the spec just in case. Got any ref for us ?

I wonder why this is necessary. This doesn't work particularly with typedef. I'm going to file a bug on the upstream of LLDB and GDB as both don't recognize this correctly.

I'm surprised that only LLDB hangs on this, although llvm-dwarfdump validates the file as valid DWARF TAGs. And with hang I mean, it freezes without even catching signals. GDB simply fails at showing the variables.

According to the specification in 2.14 Declaration Coordinates:

Any debugging information entry representing the declaration of an object,
module, subprogram or type may have DW_AT_decl_file, DW_AT_decl_line and
DW_AT_decl_column attributes, each of whose value is an unsigned integer
constant.

I interpret may word as what is followed by 1.3.12 Permissive Rather Than Prescriptive in the introduction chapter:

In this document, where the word “may” is used, the producer has the option to
follow the description or not

For now, I'm going to change this to match the C/C++ behaviour. wchar_t is supposed to be a native type. This is how clang handles it:

0x000000c2:   DW_TAG_base_type
                DW_AT_name	("wchar_t")
                DW_AT_encoding	(DW_ATE_signed)
                DW_AT_byte_size	(0x04)

We shouldn't use this type for D anyway, since wchar_t doesn't match with the specification of our wchar, plus, our wchar is supposed to be DW_ATE_UTF. On that note, I'm going to fix this to DW_TAG_base_type and make a separate PR to handle this correctly for D.

[ljmf00]

this is technically signed because it mimics the int type. This behaviour complies with clang/gcc debug info.

[ljmf00]

Since this logic belongs to DMC I'm not going to test this here, unless we have some test suite for SCPP version. I'm going to stack a PR on top of this to implement whar for D.

[ljmf00]

Can you re-review @Geod24 ?