> > Revised patch attached. It still generates the same (fixed) debug info
> > for the reduced testcase. I'll do a full testing cycle if you're happy
> > with it.
> >
> >
> > * dwarf2out.c (function_possibly_abstracted_p): New static
> > function. (gen_subprogram_die): Use it function_pos
On Wed, May 16, 2012 at 2:29 PM, Eric Botcazou wrote:
>> Right, and that's why we want your change to split the nested function
>> into abstract and concrete instances. But then it should be fine to
>> attach the abstract instance to the abstract parent normally, I would
>> think.
>
> Indeed, thi
On 05/19/2012 04:40 AM, Eric Botcazou wrote:
We attach them to the first non-abstract parent function with the loop. That's
important for Ada because we rely on the static nesting of functions in the
debug info to support up-level references in GDB (i.e. access to variables of
parent functions f
> > Does it really matter for concrete instances of inline functions?
>
> Nope. Are those the only things with an abstract origin that will end
> up on limbo?
According to the head comment of the block, yes, but I can try and see what
happens in real life.
> If we're always going to attach them
On 05/18/2012 04:48 PM, Eric Botcazou wrote:
Why do you need this change? As long as we're setting DW_AT_inline, it
shouldn't matter what its value is.
It's 0 for the nested function without it.
Ah, I thought that having DW_AT_inline of DW_INL_not_inlined was enough
to mark it as an abstrac
> Why do you need this change? As long as we're setting DW_AT_inline, it
> shouldn't matter what its value is.
It's 0 for the nested function without it.
> If we are looking at the DIE for something from a function in non-unit
> scope, this will return comp_unit_die() where previously it would h
On 05/16/2012 05:29 PM, Eric Botcazou wrote:
- if (cgraph_function_possibly_inlined_p (decl))
+ if (function_possibly_abstracted_p (decl))
add_AT_unsigned (subr_die, DW_AT_inline, DW_INL_declared_inlined);
else
add_AT_unsigned (subr_die, DW_AT_inl
> Right, and that's why we want your change to split the nested function
> into abstract and concrete instances. But then it should be fine to
> attach the abstract instance to the abstract parent normally, I would
> think.
Indeed, this works, but I need to use function_possibly_abstracted_p inst
On 05/14/2012 04:17 PM, Eric Botcazou wrote:
Our normal procedure is to generate a declaration when we see a function
in its enclosing context, and then fix it up later when we see the
definition. Why not handle this similarly?
Because we want to generate an abstract instance of the nested fun
> Our normal procedure is to generate a declaration when we see a function
> in its enclosing context, and then fix it up later when we see the
> definition. Why not handle this similarly?
Because we want to generate an abstract instance of the nested function within
the abstract instance of the
On 05/14/2012 12:49 PM, Jason Merrill wrote:
On 05/14/2012 11:54 AM, Eric Botcazou wrote:
Hmm, why isn't current_function_decl == decl when we're trying to emit
the abstract instance of a nested function?
Because it is emitted when the first instance of the parent function
is seen,
and in this
On 05/14/2012 11:54 AM, Eric Botcazou wrote:
Hmm, why isn't current_function_decl == decl when we're trying to emit
the abstract instance of a nested function?
Because it is emitted when the first instance of the parent function is seen,
and in this case current_function_decl == parent_decl.
> I notice that D.7 seems to suggest that if the nested function is not
> inlinable and shared between all instances of the containing function
> that we put a normal (non-abstract/concrete) instance of the nested
> function inside the abstract function for the containing function. But
> I agree t
On 03/02/2012 03:29 PM, Eric Botcazou wrote:
I notice that D.7 seems to suggest that if the nested function is not
inlinable and shared between all instances of the containing function
that we put a normal (non-abstract/concrete) instance of the nested
function inside the abstract function for
14 matches
Mail list logo
