Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DW_DLE_ATTR_FORM_BAD (114) ERR_INVALID_DWARF: Failed to read DWARF from 'asan.o' #7

Open
marxin opened this issue Sep 19, 2017 · 4 comments
Labels

Comments

@marxin
Copy link

marxin commented Sep 19, 2017

Hello.

Following test-case:

$ cat asan.ii
template < int b > class c {};
template < typename d > struct e {};
e< struct a > f;
struct a {
  c< 3 > g;
};

Fails with GCC 7.1.0+. Looks it started with r241085 of GCC:

SVN revision: 241085
Author: rguenth
2016-10-13  Richard Biener  <[email protected]>

	* dwarf2out.c (tree_add_const_value_attribute): Do not try
	rtl_for_decl_init during early phase.
	(gen_variable_die): Do not create locations during early phase.
	(gen_label_die): Likewise.
	(decls_for_scope): Do not waste time handling BLOCK_NONLOCALIZED_VARs
	twice.
@marxin
Copy link
Author

marxin commented Sep 19, 2017

Build with:

g++ asan.ii -g -c && ./bin/diva asan.o
DW_DLE_ATTR_FORM_BAD (114)
ERR_INVALID_DWARF: Failed to read DWARF from 'asan.o'

@FlameTop FlameTop added the bug label Sep 19, 2017
@SeanEveson
Copy link
Contributor

Reproduced: repro.zip

Looks like gcc is now outputting template parameter values in block form rather than as integers (which is valid DWARF).

 DW_TAG_template_value_parameter
   DW_AT_name                  "b" <form DW_FORM_string>
   DW_AT_type                  <0x00000072> <form DW_FORM_ref4>
   DW_AT_const_value           03000000 <form DW_FORM_block1>

This has the same underlying problem as issue #1 (quick fixed), where we could account for more forms when reading attributes, and handle forms we aren't expecting better.

@SeanEveson
Copy link
Contributor

SeanEveson commented Sep 20, 2017

As an aside I wonder why the value is now encoded as DW_FORM_block* (a collection of bytes) rather than DW_FORM_data*.

The reader of the DWARF can't interpret the value without knowing what the bytes represent. In this case they're a little endian integer but there is no way of 'knowing' that.

@jakubjelinek
Copy link

The type is the DW_AT_type on the DW_TAG_template_value_parameter. If you look at DWARF, e.g. DWARF5 pdf, block class next to constant and string are the supported classes.
While this inefficiency has been fixed in the mean time in GCC 8, if you say have template parameter with say __int128_t type that doesn't fit into 64-bits (signed or unsigned), you'll get a block too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants