search for: start_files

Hi, I would like to implement macro debug info support in LLVM. Below you will find 4 parts: 1. Background on what does it mean to debug macros. 2. A brief explanation on how to represent macro debug info in DWARF 4.0. 3. The suggested design. 4. A full example: Source -> AST -> LLVM IR -> DWARF. Feel free to skip first two parts if you think you know the background.

> Do we really need to touch the AST? Or would it be reasonable to wire up the CGDebugInfo directly to the PPCallbacks, if it isn't already? (perhaps it is already wired up for other reasons?) This sound as a good idea, I will check that approach. PPCallbacks is only an interface, has nothing connected to it, but we will create a new class, which implement PPCallbacks, for macros. So we can

> Not necessarily, if we kept the macros in order in the list of macros attached to the CU, which I imagine we would. OK, now I understand what you are aiming for. I really do not favor one on the other. But, can you explain what is the advantage of the parent approach over the children approach? If any, the children approach seems to be the one reduces the LLVM IR size, is not it? Regards,

> Right - I was wondering if CGDebugInfo already implemented PPCallbacks or was otherwise being notified of PPCallback related things, possibly through a layer or two of indirection. I checked the approach of skipping representing macros in AST, and communicate them directly from Parser to CGDebugInfo. However, I could not find a way to initialize this communication. The only interface

On Mon, Nov 9, 2015 at 4:00 AM, Aboud, Amjad <amjad.aboud at intel.com> wrote: > I found a way to skip representing macros in AST and create them directly > in CGDebugInfo through PPCallbacks during preprocessing. > > To do that, I needed to extend ASTConsumer interface with this extra > method: > > > > /// If the consumer is interested in notifications from

I'd like to jump in. I do not work on a preprocessor based language, but have the same code expansion problem to encode. Right now, we hack around the problem by appending some prefix after the file name and pretend it is a different file, which is not great. I understand you want to represent expansion by DIFileMacro ? I'm not how this is supposed to be used and it is not in the example.

On Fri, Nov 13, 2015 at 2:41 PM, Richard Smith <richard at metafoo.co.uk> wrote: > On Fri, Nov 13, 2015 at 10:21 AM, David Blaikie via cfe-dev < > cfe-dev at lists.llvm.org> wrote: > >> On Mon, Nov 9, 2015 at 4:00 AM, Aboud, Amjad <amjad.aboud at intel.com> >> wrote: >> >>> I found a way to skip representing macros in AST and create them

...ra 4096 Feb 8 06:17 crosshatch_dir drwxrwx--x 2 bpaolo poliedra 4096 Feb 8 06:17 format_dir drwxrwx--x 2 bpaolo poliedra 4096 Feb 8 06:17 material_dir drwxrwx--x 3 bpaolo poliedra 4096 Feb 8 06:17 plotter_dir drwxrwx--x 2 bpaolo poliedra 4096 Feb 8 06:17 start_files drwxrwx--x 2 bpaolo poliedra 4096 Feb 8 06:17 symbol_dir drwxrwx--x 2 bpaolo poliedra 4096 Feb 8 06:17 templates -rw-rw---- 1 bpaolo poliedra 79 Dec 17 1999 tree.cfg ./proe/configs: total 36 drwxrwx--x 2 bpaolo poliedra 4096 Feb 8 06:17 . drwxrwx--x 10 b...