This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Fix two problems with reorder_blocks and debugging
- From: Mark Mitchell <mark at codesourcery dot com>
- To: gcc-patches at gcc dot gnu dot org
- Date: Fri, 21 Jul 2006 20:18:36 -0700
- Subject: Re: Fix two problems with reorder_blocks and debugging
- References: <20060722020212.GA1282@nevyn.them.org>
Daniel Jacobowitz wrote:
> output the parents of blocks to output the blocks. So in the end it
> generates this tree:
>
> A
> -> B
> -> B
> -> C
>
> The first copy of B has the block's local variables in it. The second copy
> doesn't.
> I fixed this by attaching all blocks to the origin.
Would you please say a bit more about the fix? What's the origin? I
expected you to say (after the bit above), "so, I made sure both copies
of B had the block's local variables". But, thinking about it, that
doesn't seem like it would be valid DWARF. So, can you say a bit about
what DWARF we emit with your patch and what the internal block/fragment
tree looks like with your change?
> I tested this patch by eye on x86_64-pc-linux-gnu (since neither the GCC nor
> GDB testsuites exercise optimized debug info at the moment). I also
> regression tested it twice, once with strategic aborts in
> reorder_fix_fragments to make sure it really wasn't doing anything.
>
> OK to commit?
Can we write a testcase for this, in either the GCC or GDB testsuite?
Do you know if this is a regression? Is their optimized code that was
more debuggable before?
Thanks,
--
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713