search for: dimacrofile

...e only drawback with this approach, is that we can test the frontend using the generated LLVM IR, i.e. the whole path, instead of having two tests, AST for testing the parser, and LLVM IR for testing the Sema. > I wonder if it'd be better to use a parent chain style approach (DIMacro has a DIMacroFile it refers to, each DIMacroFile has another one that it refers to, up to null)? > (does it ever make sense/need to have a DIMacroFile without any macros in it? I assume not?) First, it seems that GCC does emit MacroFile that has no macros inside (I understand that it might not be useful, but I am...

...LLVM IR for testing the Sema. We don't usually do direct AST tests in Clang for debug info (or for many things, really) - we just do source -> llvm IR anyway, so that's nothing out of the ordinary. > I wonder if it'd be better to use a parent chain style approach (DIMacro has a DIMacroFile it refers to, each DIMacroFile has another one that it refers to, up to null)? > (does it ever make sense/need to have a DIMacroFile without any macros in it? I assume not?) First, it seems that GCC does emit MacroFile that has no macros inside (I understand that it might not be useful, but I am...

...LLVM IR for testing the Sema. We don't usually do direct AST tests in Clang for debug info (or for many things, really) - we just do source -> llvm IR anyway, so that's nothing out of the ordinary. > I wonder if it'd be better to use a parent chain style approach (DIMacro has a DIMacroFile it refers to, each DIMacroFile has another one that it refers to, up to null)? > (does it ever make sense/need to have a DIMacroFile without any macros in it? I assume not?) First, it seems that GCC does emit MacroFile that has no macros inside (I understand that it might not be useful, but I am...

...usually do direct AST tests in Clang for debug info (or for many > things, really) - we just do source -> llvm IR anyway, so that's nothing > out of the ordinary. > > > > > > > I wonder if it'd be better to use a parent chain style approach (DIMacro > has a DIMacroFile it refers to, each DIMacroFile has another one that it > refers to, up to null)? > > (does it ever make sense/need to have a DIMacroFile without any macros > in it? I assume not?) > First, it seems that GCC does emit MacroFile that has no macros inside (I > understand that it migh...

...g for debug info (or for many >> things, really) - we just do source -> llvm IR anyway, so that's nothing >> out of the ordinary. >> >> >> >> >> >> > I wonder if it'd be better to use a parent chain style approach >> (DIMacro has a DIMacroFile it refers to, each DIMacroFile has another one >> that it refers to, up to null)? >> > (does it ever make sense/need to have a DIMacroFile without any macros >> in it? I assume not?) >> First, it seems that GCC does emit MacroFile that has no macros inside (I >> und...

...; many things, really) - we just do source -> llvm IR anyway, so that's >>> nothing out of the ordinary. >>> >>> >>> >>> >>> >>> > I wonder if it'd be better to use a parent chain style approach >>> (DIMacro has a DIMacroFile it refers to, each DIMacroFile has another one >>> that it refers to, up to null)? >>> > (does it ever make sense/need to have a DIMacroFile without any macros >>> in it? I assume not?) >>> First, it seems that GCC does emit MacroFile that has no macros inside...

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.

Hello Everyone, I would like to have your thoughts on this. Overview of the problem =================== While implementing support for the DWARFv5 debug_macro section support in LLVM. I came across these holes: - The macros infrastructure in CLANG/LLVM is inherently tied to a particular version(v4 macinfo). For instance, consider this snippet from CLANG: