This is an archive of the discontinued LLVM Phabricator instance.

Module: add debug_type to dump debugging messages related to modules being out of date
Needs ReviewPublic

Authored by manmanren on Jul 21 2016, 11:34 AM.

Details

Summary

This is a patch I applied internally to debug out-of-date issues. In general is this the right way to add debugging messages in clang frontend?

I wonder how we debug module-related issues. This patch adds DEBUG_TYPE to various source files that are module related, to enable the debugging, we need an assert build of the compiler. Is it better to add a cc1 option to dump debugging messages even for a no-assert (release) build of the compiler?

Diff Detail

Event Timeline

manmanren updated this revision to Diff 64932.Jul 21 2016, 11:34 AM
manmanren retitled this revision from to Module: add debug_type to dump debugging messages related to modules being out of date.
manmanren updated this object.
manmanren added reviewers: benlangmuir, rsmith.
manmanren added a subscriber: cfe-commits.
manmanren updated this object.Oct 17 2016, 3:39 PM
manmanren added reviewers: bruno, v.g.vassilev.
v.g.vassilev edited edge metadata.Oct 18 2016, 4:48 AM

I am not sure whether that's useful for debugging out-of-date issues but this is what I use and it is helpful.

Some debugging aids (suggested by Richard Smith):

-fdiagnostics-show-note-include-stack will tell you which module a note comes from
#pragma clang __debug dump X allows you to produce an AST dump from within a source file, so you can see which modules declare a given name
#pragma clang __debug macro M allows you to dump a macro, which can be useful to see which module(s) export visible include guards for a header

If a name is not visible in a modules build but is visible in a non-modules build, i usually find that's due to one of two things

some part of the machinery that provides it depends on macro definitions leaking into a modular header from outside, or
there is an include cycle involving a modular header and a non-modular header

Also, creduce (I've specialized it a bit for modules) helps reducing the modules complexity (https://github.com/vgvassilev/creduce/blob/master/USAGE.md#reducing-clang-c-modules-bugs). After reduction, the debugger is much more useful.

Thanks a lot for the pointers!

I will definitely try them. What I proposed here is something similar to what llvm does that dumps logging messages, it should be complementary to your debugging aids.

Manman

I am not sure whether that's useful for debugging out-of-date issues but this is what I use and it is helpful.

Some debugging aids (suggested by Richard Smith):

-fdiagnostics-show-note-include-stack will tell you which module a note comes from
#pragma clang __debug dump X allows you to produce an AST dump from within a source file, so you can see which modules declare a given name
#pragma clang __debug macro M allows you to dump a macro, which can be useful to see which module(s) export visible include guards for a header

If a name is not visible in a modules build but is visible in a non-modules build, i usually find that's due to one of two things

some part of the machinery that provides it depends on macro definitions leaking into a modular header from outside, or
there is an include cycle involving a modular header and a non-modular header

How do we proceed with this. Shall we close it?

@bruno, what's the fate of this?

bruno resigned from this revision.Nov 9 2020, 11:52 AM