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]

[fortran,patch] Register entering/exiting source files, handling macro definitions debug info


Attached is my updated patch for PR33502: the first patch was reverted
after discovering that it screwed update -gstabs completely (thus
inducing bootstrap failures on targets that use stabs as default debug
format). The explanation in the original patch still stands
(http://gcc.gnu.org/ml/gcc-patches/2007-09/msg01721.html), which was
rather detailed, still stands, so I copy-pasted bits of it for the
paragraphs below.

The Fortran front-end currently thinks the only preprocessor lines it
can be given are location lines (of the form: # linenum "filename").
This is not true for verbose debug (-g3): in that case, #define and
#undef preprocessor directives are included in the preprocessed file,
so that they debug info can be emitted for macros. The Fortran
front-end not only doesn't emit such debug information, but it even
chokes on the preprocessor lines. The first half of the patch fixes
that: We first encounter the #define and #undef lines when loading the
file; at that time, however, it's too early to emit debug info (the
compiler hasn't yet setup the output file), so we just have to ignore
them (that's the part in scanner.c:load_file). Later, when we actually
parse the source, we can actually handle them: in next_statement
[parse.c], we call about new function gfc_define_undef_line
[scanner.c], which calls debug_hooks->define and debug_hooks->undef.

However, doing so requires that we tell the middle-end (via the debug
target hooks) whenever we enter or exit a source file, ie whenever the
filename changes. I also discovered (serendipity!), while
investigating PR33408, that our current behaviour of not doing so
leads to bad memory references in the middle-end for stabs,
potentially triggering ICEs (at least one concrete example of this was
the initial report for PR33408, on powerpc-darwin).

The patch was regtested on x86_64-linux, with the following
combinations of options: -m64, -m64 -g3, -m64 -gstabs, -m32 -gstabs,
-m64 -gstabs+. OK to commit?


PS: I have learnt this one thing: stabs is apparently less forgiving
that dwarf when it comes to these debug info problems, so it's a very
good idea to test both, as they're both enabled by default on
(i386|x86_64)-linux.


:ADDPATCH fortran:

Attachment: pr33502_2.ChangeLog
Description: Binary data

Attachment: pr33502_2.diff
Description: Binary data


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