This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Designs for better debug info in GCC
- From: "Steven Bosscher" <stevenb dot gcc at gmail dot com>
- To: "Alexandre Oliva" <aoliva at redhat dot com>
- Cc: "Mark Mitchell" <mark at codesourcery dot com>, "Ian Lance Taylor" <iant at google dot com>, "Richard Guenther" <richard dot guenther at gmail dot com>, gcc-patches at gcc dot gnu dot org, gcc at gcc dot gnu dot org
- Date: Sat, 24 Nov 2007 00:56:47 +0100
- Subject: Re: Designs for better debug info in GCC
- References: <571f6b510711121208m2bf7c77fp884f52d458df118b@mail.gmail.com> <orpry0k7xg.fsf@oliva.athome.lsd.ic.unicamp.br>
On Nov 23, 2007 9:45 PM, Alexandre Oliva <aoliva@redhat.com> wrote:
> So, yes, debug stmts and insns are notes in the sense that they don't
> output code. Like USE insns, labels, empty asm insns and other
> UNSPECs. But wait, those are insns, not notes. And they do generate
> code, just not in the .text section, but rather in .debug sections.
All of them relate to code generation though. Without them, we create
wrong code. I'm aware of how you feel about debug info and
correctness and so on.
> So, what's this prejudice against debug insns? Why do you regard them
> as notes rather than insns?
What worries me is that GCC will have to special-case DEBUG_INSN
everywhere where it looks at INSNs. One can already see some of that
happening on your branch. Apparently, you can't treat DEBUG_INSN just
like any other normal insn.
What I see happening with your DEBUG_INSN approach, is that all passes
that use NEXT_INSN/PREV_INSN will have to special-case DEBUG_INSN in
addition to the NOTE_P or INSN_P checks that they already have. I
have seen too many bugs with passes who forgot to look through notes
to feel comfortable about adding another
not-a-note-but-also-not-an-insn like thing to the insn stream. The
fact that DEBUG_INSN also has real operands that are not really real
operands is bound to confuse the matter even more. Life with proper
insn and operands iterators for RTL would be so much easier, but for
the moment I fear you're just going to see a lot of duplication of
ugly conditionals and bugs where such conditionals are
forgotten/overlooked/missing.
So to summarize: I'm just worried your approach is going to make GCC
even slower, buggier, more difficult to maintain and more difficult to
understand and modify. And the benefit, well, let's just say I'm not
convinced that less elaborate efforts are not sufficient.
(And to be perfectly honest, I think GCC has bigger issues to solve
than getting perfect debug info -- such as getting compile times of a
linux kernel down ;-))
Gr.
Steven