On 03/26/2013 03:29 PM, Eric Botcazou wrote:
Heh. We've actually fixed this now -- unwind info generation aware of
the cfg is exactly what pass_dwarf2_frame does. So I guess this comment
has been out of date since gcc 4.7.
I see, thanks. So what do you suggest doing at this point?
Isn't pass_dwarf2_frame enabled whenever we're generating any unwind info?
Essentially, yes:
static bool
gate_dwarf2_frame (void)
{
#ifndef HAVE_prologue
/* Targets which still implement the prologue in assembler text
cannot use the generic dwarf2 unwinding. */
return false;
#endif
Heh. We've actually fixed this now -- unwind info generation aware of
the cfg is exactly what pass_dwarf2_frame does. So I guess this comment
has been out of date since gcc 4.7.
I see, thanks. So what do you suggest doing at this point? Entirely remove
the block of code? But AFAICS
Hi,
process_options has had these lines for a couple of releases:
/* ??? Unwind info is not correct around the CFG unless either a frame
pointer is present or A_O_A is set. Fixing this requires rewriting
unwind info generation to be aware of the CFG and propagating states
On 03/25/2013 04:26 AM, Eric Botcazou wrote:
process_options has had these lines for a couple of releases:
/* ??? Unwind info is not correct around the CFG unless either a frame
pointer is present or A_O_A is set. Fixing this requires rewriting
unwind info generation to be aware