This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Designs for better debug info in GCC
On Dec 17, 2007, Joe Buck <Joe.Buck@synopsys.COM> wrote:
> On Mon, Dec 17, 2007 at 11:11:46PM -0200, Alexandre Oliva wrote:
>> Line number information has a well-defined meaning: it ought to
>> represent the source code line that best represents the source-code
>> construct that ended up implemented using that instruction.
> You implicitly assume that souch a source code line exists.
Actually, no. I'm not sure where you got that impression, and how you
came to the conclusion that I'd assign line numbers the way you have.
To me, when you hoist something that is present in both blocks of a
conditional, it probably makes more sense to give it the line number
of the conditional, rather than that of either block. But I won't
pretend to have thought very hard about this particular issue. For
the time being, I'm focusing my efforts on local variable locations.
Anyhow, very clearly you don't want to mark such hoisted-out
computation as is_stmt. This should eliminate at least the solvable
problem you're worried about.
> out = a + b;
> if (!cond)
> out += c;
> return out;
> Furthermore, there isn't a place to put a breakpoint that will
> trigger only for the case where cond is true, as you can on
> unoptimized code.
Yep. Sometimes code just is optimized away. Can't stop that without
harming optimizations.
If dwarf line number programs were smarter, we could perhaps encode
multiple lines for the same instruction, along with conditions to tell
when the instruction applies to such or such lines, and even more
fancy stuff like that. But line number programs don't let us express
this in Dwarf3.
--
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member http://www.fsfla.org/
Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org}