This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Fix two problems with reorder_blocks and debugging


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]