--- Comment #11 from rguenther at suse dot de <rguenther at suse dot de> ---
On Thu, 8 Feb 2018, derodat at adacore dot com wrote:
> --- Comment #10 from Pierre-Marie de Rodat <derodat at adacore dot com> ---
> (In reply to Richard Biener from comment #8)
> > Yeah, setting DECL_PRESERVE_P would make it possible to add the
> > location late since we'd not remove the decl. Currently it's simply
> > gone and the early dwarf2out_"late"_global_decl is the last thing
> > we see from it...
> Ok, understood.
> > Currently struggling in getting a debuggable gnat1 built .. it looks
> > like ./configure --enable-languages=c++,ada --disable-bootstrap
> > no longer works with a host compiler that doesn't understand some
> > C++ specs that appear to be used (GCC 4.8).
> I’m using GCC 7.2.1. It’s odd that you get this issue only with gnat1, though…
> (In reply to Richard Biener from comment #9)
> > Another possibility would be to add the info symbolically by refering to the
> > early DIE of the other entity. Not sure if that works for the Ada cases?
> > We have
> > DW_OP_GNU_variable_value but in this case we want the DIEs address.
> In the original ADa use case, there is no other entity: the variable for which
> we want to emit a location is around only for its name, so instead of
> allocating a memory slot for it, we produce a “dummy” location (DW_OP_const1s:
> -1). So I don’t know: would what you have in mind work? (just keeping
> a location is enough for Ada, I think)
Ah, ok. A DW_OP_const1s location is fine early ;)
> > Btw, if you compile any of your testcases for the issue with -g -flto
> > can you verify if the generated object files contain relocations in the
> > early LTO debug sections? Those should not refer to real symbols...
> > else the problem will manifest with Ada as well.
> I’m confused: is this query for myself or for one Martin? ;-)
For you but the above clears it - a DW_OP_const1s doesn't produce a
relocation ;) This means you should be able to arrange for this
to be emitted by tree_add_const_value_attribute_for_decl as well, no?
> > So I think we do have to revert the revision in question (or put in the
> > above hack).
> Either way, in the end we need a solution that fixes the SPEC build error and
> that does not make Ada debugging regress. :-)
> I’m still not familiar with LTO and how early/late passes are supposed to
> so I lack judgment about what is a hack and what isn’t. Do you think we can
> find a clean way to delay location production from the “early late” pass to
> “truly late” one?
See above - I think we should emit this special value from
tree_add_const_value_attribute_for_decl instead, reverting the original
As I can't seem to get a gnat1 debugged right now can you try to
see what would be necessary to do that? How's the DECL_VALUE_EXPR