vivek pandya via llvm-dev
2015-Nov-14 07:42 UTC
[llvm-dev] llvm-dev Digest, Vol 137, Issue 59
On Sat, Nov 14, 2015 at 5:18 AM, via llvm-dev <llvm-dev at lists.llvm.org> wrote:> Send llvm-dev mailing list submissions to > llvm-dev at lists.llvm.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > or, via email, send a message with subject or body 'help' to > llvm-dev-request at lists.llvm.org > > You can reach the person managing the list at > llvm-dev-owner at lists.llvm.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of llvm-dev digest..." > > > Today's Topics: > > 1. Re: 2015 LLVM Developers' Meeting videos are up! > (Mehdi Amini via llvm-dev) > 2. Re: [cfe-dev] RFC: Supporting macros in LLVM debug info > (David Blaikie via llvm-dev) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 13 Nov 2015 15:42:05 -0800 > From: Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org> > To: Tanya Lattner <tanyalattner at llvm.org> > Cc: LLVM Dev <llvm-dev at lists.llvm.org> > Subject: Re: [llvm-dev] 2015 LLVM Developers' Meeting videos are up! > Message-ID: <4F6F138E-3791-426F-AF8B-321886769210 at apple.com> > Content-Type: text/plain; charset="utf-8" > > Hi Tanya, > > > On Nov 13, 2015, at 12:44 PM, Tanya Lattner via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > The videos for the 2015 LLVM Developers’ Meeting may be found on our > YouTube channel (https://www.youtube.com/channel/UCv2_41bSAa5Y_8BacJUZfjQ > <https://www.youtube.com/channel/UCv2_41bSAa5Y_8BacJUZfjQ>). Here is the > link to the playlist: > > https://youtu.be/5W7NkofUtAw?list=PL_R5A0lGi1AA4Lv2bBFSwhgDaHvvpVU21 < > https://youtu.be/5W7NkofUtAw?list=PL_R5A0lGi1AA4Lv2bBFSwhgDaHvvpVU21> > It is the first time that the videos are not available to download I > think? That’s unfortunate :( > Any chance to also have a download option provided? > Do BoF sessions have videos ? > For instance CppCon 2015 provides videos on youtube: > https://www.youtube.com/watch?v=1OEu9C51K2A > as well as on Channel9 where you can download them: > https://channel9.msdn.com/Events/CPP/CppCon-2015/Writing-Good-C-14 > > Thanks, > > — > Mehdi > > > > > > Subscribe to our channel for updates! Links to slides may be found in > the video descriptions. > > > > A huge thank you to our video production company Bash Films for the > amazingly quick turn around. We think you will love the quality of the > videos this year! I welcome any feedback you have about the videos this > year. > > > > I will also be adding talk descriptions and links to all the videos, > posters, slides, etc to the 2015 LLVM Developers’ Meeting website ( > http://llvm.org/devmtg/2015-10/ <http://llvm.org/devmtg/2015-10/>). > Thank you for your patience on this. > > > > Thanks, > > Tanya > > > > > > _______________________________________________ > > LLVM Developers mailing list > > llvm-dev at lists.llvm.org > > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://lists.llvm.org/pipermail/llvm-dev/attachments/20151113/874d10c6/attachment-0001.html > > > > ------------------------------ > > Message: 2 > Date: Fri, 13 Nov 2015 15:50:49 -0800 > From: David Blaikie via llvm-dev <llvm-dev at lists.llvm.org> > To: Richard Smith <richard at metafoo.co.uk> > Cc: "llvm-dev at lists.llvm.org" <llvm-dev at lists.llvm.org>, > "cfe-dev at lists.llvm.org" <cfe-dev at lists.llvm.org> > Subject: Re: [llvm-dev] [cfe-dev] RFC: Supporting macros in LLVM debug > info > Message-ID: > <CAENS6EteTBKgG0Dbo> cjhjgdoE8hYapa7nx8aWj_9ce4MbvVtA at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > On Fri, Nov 13, 2015 at 3:41 PM, Richard Smith <richard at metafoo.co.uk> > wrote: > > > On Fri, Nov 13, 2015 at 2:49 PM, David Blaikie <dblaikie at gmail.com> > wrote: > > > >> 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 > >>>>> 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 > Preprocessor, > >>>>> > >>>>> /// for example: notifications on macro definitions, etc., it > >>>>> should return > >>>>> > >>>>> /// a pointer to a PPCallbacks here. > >>>>> > >>>>> /// The caller takes ownership on the returned pointer. > >>>>> > >>>>> virtual PPCallbacks *CreatePreprocessorCallbacks() { return > nullptr; > >>>>> } > >>>>> > >>>>> > >>>>> > >>>>> Then the ParseAST can use it to add these preprocessor callbacks, > >>>>> which are needed by the AST consumer, to the preprocessor: > >>>>> > >>>>> > >>>>> > >>>>> S.getPreprocessor().addPPCallbacks( > >>>>> > >>>>> std::unique_ptr<PPCallbacks > >>>>> >(Consumer->CreatePreprocessorCallbacks())); > >>>>> > >>>> > >>>> (CreatePreprocessorCallbacks, if that's the path we take, should > return > >>>> a unique_ptr itself rather than returning a raw ownership-passing > pointer, > >>>> but that's a minor API detail) > >>>> > >>>> > >>>>> > >>>>> > >>>>> With this, approach the change in clang to support macros is very > >>>>> small. > >>>>> > >>>>> > >>>>> > >>>>> Do you agree to this approach? > >>>>> > >>>> > >>>> Richard - what do you reckon's the right hook/path to get preprocessor > >>>> info through to codegen (& CGDebugInfo in particular). Would a general > >>>> purpose hook in the ASTConsumer be appropriate/useful? > >>>> > >>> > >>> ASTConsumer shouldn't know anything about the preprocessor; there's no > >>> reason to think, in general, that the AST is being produced by > >>> preprocessing and parsing some text. > >>> > >> > >> Hmm, I suppose a fair question then - would it be possible to implement > >> debug info for macros when reading ASTs from a serialized file (without > a > >> preprocessor). Or should we actually go with the original proposal of > >> creating AST nodes for the preprocessor events so we can have access to > >> them after loading serialized modules & then generating debug info from > >> them? Is there some other side table we'd be better off using/creating > for > >> this task? > >> > > > > It would make sense to split the preprocessor into separate layers for > > holding the macro / other state information and for actually performing > > preprocessing (that is, we'd have a separate "preprocessor AST" > containing > > just the macro information), similar to the AST / Sema split, but that's > a > > rather large task. In the mean time, we would need to require people to > set > > up a preprocessor to deserialize into (even though they're never going to > > actually preprocess anything) so that they have somewhere to put the > macros > > before feeding them to CodeGen. That doesn't seem like a huge imposition. > > > > Maybe it's just the week I've had (& perhaps Amjad can make more sense of > it) but I'm having a hard time picturing waht you're suggesting. > > You're saying currently when loading modules (which do have macros & such > in them, so there's some "preprocessor-y" things going on) we do > <something> but instead/in addition we could build a Preprocessor and > populate it (it doesn't have any representation for this currently? we'd > have to add a side table in Preprocessor for these reconstituted macro > things?) from the module - then, separately, decide how the information > gets from the Preprocessor to CodeGen? > > > > > > But the case I was thinking of wasn't actually deserialized ASTs (for > > which there usually is some preprocessor state available somewhere), it's > > cases like lldb, swig-like tools or clang plugins that synthesize AST > nodes > > out of thin air. CodeGen should be prepared to generate code from a world > > where no preprocessor ever existed, and we shouldn't make the ASTConsumer > > interface imply that macros are part of the AST -- we should present them > > as an (optional) separate layer. > > > > OK - any ideas/suggestions/preferences on how we get the stuff in > Preprocessor into CodeGen/CGDebugInfo? I'm just not quite picturing how > this all lines up, but haven't looked at the boundaries in much detail/know > them well. > > Thanks a bunch, > - Dave > > > > > > Perhaps adding a PreprocessorConsumer interface akin to the existing > >>> SemaConsumer interface would be a better way to go. > >>> > >> > >>> Thanks, > >>>>> > >>>>> Amjad > >>>>> > >>>>> > >>>>> > >>>>> *From:* llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] *On Behalf > >>>>> Of *Aboud, Amjad via llvm-dev > >>>>> *Sent:* Thursday, November 05, 2015 16:56 > >>>>> *To:* David Blaikie > >>>>> > >>>>> *Cc:* llvm-dev at lists.llvm.org > >>>>> *Subject:* Re: [llvm-dev] RFC: Supporting macros in LLVM debug info > >>>>> > >>>>> > >>>>> > >>>>> > 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 available through Parser is either Sema (to create > >>>>> an AST) or ASTConsumer. While the CGDebugInfo is only available in > the > >>>>> CodeGenModule, which is accessible from BackendConsumer, that > implements > >>>>> ASTConsumer. > >>>>> > >>>>> > >>>>> > >>>>> David, skipping the AST will save a lot of code, but I need help > >>>>> figuring out how to communicate with the CGDebugInfo. > >>>>> > >>>>> > >>>>> > >>>>> Thanks, > >>>>> > >>>>> Amjad > >>>>> > >>>>> > >>>>> > >>>>> *From:* David Blaikie [mailto:dblaikie at gmail.com <dblaikie at gmail.com > >] > >>>>> > >>>>> *Sent:* Tuesday, November 03, 2015 18:46 > >>>>> *To:* Aboud, Amjad > >>>>> *Cc:* llvm-dev at lists.llvm.org > >>>>> *Subject:* Re: [llvm-dev] RFC: Supporting macros in LLVM debug info > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> On Tue, Nov 3, 2015 at 12:16 AM, Aboud, Amjad <amjad.aboud at intel.com > > > >>>>> wrote: > >>>>> > >>>>> > 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. > >>>>> > >>>>> > >>>>> > >>>>> 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. > >>>>> > >>>>> > >>>>> > >>>>> So we can connect whatever we want to that class. > >>>>> > >>>>> The 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. > >>>>> > >>>>> > >>>>> > >>>>> 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 not sure if we > should > >>>>> ignore that or not). > >>>>> > >>>>> > >>>>> > >>>>> Yeah, that's weird - I'd sort of be inclined to skip it until we know > >>>>> what it's useful for. > >>>>> > >>>>> > >>>>> > >>>>> Second, I assume that you are suggesting the parent chain style > >>>>> instead to the current children style, right? > >>>>> > >>>>> > >>>>> > >>>>> Correct > >>>>> > >>>>> > >>>>> > >>>>> In this case, won’t it make the debug emitter code much complicated > to > >>>>> figure out the DFS tree, > >>>>> > >>>>> > >>>>> > >>>>> I don't quite imagine it would be more complicated - we would just be > >>>>> building the file parent chain as we go, and keeping the current > macro file > >>>>> around to be used as the parent to any macros we create. > >>>>> > >>>>> > >>>>> > >>>>> which should be emitted for the macros, not mentioning the macro > order > >>>>> which will be lost? > >>>>> > >>>>> > >>>>> > >>>>> Not necessarily, if we kept the macros in order in the list of macros > >>>>> attached to the CU, which I imagine we would. > >>>>> > >>>>> > >>>>> > >>>>> Also, remember that the command line macros have no DIMacroFile > parent. > >>>>> > >>>>> > >>>>> > >>>>> Fair - they could have the null parent, potentially. > >>>>> > >>>>> > >>>>> > >>>>> However, if you meant to use the parent chain in addition to the > >>>>> children list, then what extra information it will give us? > >>>>> > >>>>> > >>>>> > >>>>> >Might be good to start with dwarfdump support - seems useful > >>>>> regardless of anything else? > >>>>> > >>>>> I agree, and in fact, I already have this code implemented, will > >>>>> upload it for review soon. > >>>>> > >>>>> > >>>>> > >>>>> Cool > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> Thanks, > >>>>> > >>>>> Amjad > >>>>> > >>>>> > >>>>> > >>>>> *From:* David Blaikie [mailto:dblaikie at gmail.com] > >>>>> *Sent:* Tuesday, November 03, 2015 00:32 > >>>>> *To:* Aboud, Amjad > >>>>> *Cc:* llvm-dev at lists.llvm.org > >>>>> *Subject:* Re: [llvm-dev] RFC: Supporting macros in LLVM debug info > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> On Wed, Oct 28, 2015 at 7:56 AM, Aboud, Amjad via llvm-dev < > >>>>> llvm-dev at lists.llvm.org> wrote: > >>>>> > >>>>> 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. > >>>>> > >>>>> Please, let me know if you have any comment or feedback on this > >>>>> approach. > >>>>> > >>>>> > >>>>> > >>>>> Thanks, > >>>>> > >>>>> Amjad > >>>>> > >>>>> > >>>>> > >>>>> *[Background]* > >>>>> > >>>>> There are two kind of macro definition: > >>>>> > >>>>> 1. Simple macro definition, e.g. #define M1 Value1 > >>>>> > >>>>> 2. Function macro definition, e.g. #define M2(x, y) (x) + (y) > >>>>> > >>>>> Macro scope starts with the "#define" directive and ends with > "#undef" > >>>>> directive. > >>>>> > >>>>> > >>>>> > >>>>> GDB supports debugging macros. This means, it can evaluate the macro > >>>>> expression for all macros, which have a scope that interleaves with > the > >>>>> current breakpoint. > >>>>> > >>>>> For example: > >>>>> > >>>>> GDB command: print M2(3, 5) > >>>>> > >>>>> GDB Result: 8 > >>>>> > >>>>> > >>>>> > >>>>> GDB can evaluate the macro expression based on the ".debug_macroinfo" > >>>>> section (DWARF 4.0). > >>>>> > >>>>> > >>>>> > >>>>> *[DWARF 4.0 ".debug_macroinfo" section]* > >>>>> > >>>>> In this section there are 4 kinds of entries > >>>>> > >>>>> 1. DW_MACROINFO_define > >>>>> > >>>>> 2. DW_MACROINFO_undef > >>>>> > >>>>> 3. DW_MACROINFO_start_file > >>>>> > >>>>> 4. DW_MACROINFO_end_file > >>>>> > >>>>> > >>>>> > >>>>> Note: There is a 5th kind of entry for vendor specific macro > >>>>> information, that we do not need to support. > >>>>> > >>>>> > >>>>> > >>>>> The first two entries contain information about the line number where > >>>>> the macro is defined/undefined, and a null terminated string, which > contain > >>>>> the macro name (followed by the replacement value in case of a > definition, > >>>>> or a list of parameters then the replacement value in case of > function > >>>>> macro definition). > >>>>> > >>>>> The third entry contains information about the line where the file > was > >>>>> included followed by the file id (an offset into the files table in > the > >>>>> debug line section). > >>>>> > >>>>> The fourth entry contains nothing, and it just close the previous > >>>>> entry of third kind (start_file) . > >>>>> > >>>>> > >>>>> > >>>>> Macro definition and file including entries must appear at the same > >>>>> order as they appear in the source file. Where all macro entries > between > >>>>> "start_file" and "end_file" entries represent macros appears > >>>>> directly/indirectly in the included file. > >>>>> > >>>>> > >>>>> > >>>>> Special cases: > >>>>> > >>>>> 1. The main source file should be the first "start_file" entry > >>>>> in the sequence, and should have line number "0". > >>>>> > >>>>> 2. Command line/Compiler definitions must also have line number > >>>>> "0" but must appear before the first "start_file" entry. > >>>>> > >>>>> 3. Command line include files, must also have line number "0" > >>>>> but will appear straight after the "start_file" of the main source. > >>>>> > >>>>> > >>>>> > >>>>> *[Design]* > >>>>> > >>>>> To support macros the following components need to be modified: > Clang, > >>>>> LLVM IR, Dwarf Debug emitter. > >>>>> > >>>>> > >>>>> > >>>>> In clang, we need to handle these source directives: > >>>>> > >>>>> 1. #define > >>>>> > >>>>> 2. #undef > >>>>> > >>>>> 3. #include > >>>>> > >>>>> The idea is to make a use of "PPCallbacks" class, which allows > >>>>> preprocessor to notify the parser each time one of the above > directives > >>>>> occurs. > >>>>> > >>>>> These are the callbacks that should be implemented: > >>>>> > >>>>> "MacroDefined", "MacroUndefined", "FileChanged", and > >>>>> "InclusionDirective". > >>>>> > >>>>> > >>>>> > >>>>> AST will be extended to support two new DECL types: "MacroDecl" and > >>>>> "FileIncludeDecl". > >>>>> > >>>>> > >>>>> > >>>>> 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?) > >>>>> > >>>>> > >>>>> > >>>>> Where "FileIncludeDecl" AST might contain other > >>>>> "FileIncludeDecl"/"MacroDecl" ASTs. > >>>>> > >>>>> These two new AST DECLs are not part of TranslationUnitDecl and are > >>>>> handled separately (see AST example below). > >>>>> > >>>>> > >>>>> > >>>>> In the LLVM IR, metadata debug info will be extended to support new > >>>>> DIs as well: > >>>>> > >>>>> "DIMacro", "DIFileInclude", and "MacroNode". > >>>>> > >>>>> The last, is needed as we cannot use DINode as a base class of > >>>>> "DIMacro" and DIFileInclude" nodes. > >>>>> > >>>>> > >>>>> > >>>>> DIMacro will contain: > >>>>> > >>>>> · type (definition/undefinition). > >>>>> > >>>>> · line number (interger). > >>>>> > >>>>> · name (null terminated string). > >>>>> > >>>>> · replacement value (null terminated string - optional). > >>>>> > >>>>> > >>>>> > >>>>> DIFileMacro will contain: > >>>>> > >>>>> · line number (interger). > >>>>> > >>>>> · file (DIFile). > >>>>> > >>>>> · macro list (MacroNodeArray) - optional. > >>>>> > >>>>> > >>>>> > >>>>> 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?) > >>>>> > >>>>> > >>>>> Might be good to start with dwarfdump support - seems useful > >>>>> regardless of anything else? > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> In addition, the DICompileUnit will contain a new optional field of > >>>>> macro list of type (MacroNodeArray). > >>>>> > >>>>> > >>>>> > >>>>> Finally, I assume that macro support should be disabled by default, > >>>>> and there should be a flag to enable this feature. I would say that > we > >>>>> should introduce a new specific flag, e.g. "-gmacro", that could be > used > >>>>> with "-g". > >>>>> > >>>>> > >>>>> > >>>>> *[Example]* > >>>>> > >>>>> Here is an example that demonstrate the macro support from > >>>>> Source->AST->LLVM IR->DWARF. > >>>>> > >>>>> > >>>>> > >>>>> Source > >>>>> > >>>>> ========================================================> >>>>> > >>>>> mainfile.c: > >>>>> > >>>>> > >>>>> > -------------------------------------------------------------------------------------- > >>>>> > >>>>> 1. #define M1 Value1 > >>>>> > >>>>> 2. #include "myfile.h" > >>>>> > >>>>> 3. #define M2( x , y) ( (x) + (y) * Value2) > >>>>> > >>>>> > >>>>> > -------------------------------------------------------------------------------------- > >>>>> > >>>>> > >>>>> > >>>>> myfile.h: > >>>>> > >>>>> > >>>>> > -------------------------------------------------------------------------------------- > >>>>> > >>>>> 1. > >>>>> > >>>>> 2. > >>>>> > >>>>> 3. > >>>>> > >>>>> 4. #undef M1 > >>>>> > >>>>> 5. #define M1 NewValue1 > >>>>> > >>>>> > >>>>> > -------------------------------------------------------------------------------------- > >>>>> > >>>>> > >>>>> > >>>>> myfile2.h: > >>>>> > >>>>> > >>>>> > -------------------------------------------------------------------------------------- > >>>>> > >>>>> 1. #define M4 Value4 > >>>>> > >>>>> > >>>>> > -------------------------------------------------------------------------------------- > >>>>> > >>>>> ========================================================> >>>>> > >>>>> > >>>>> > >>>>> Command line: > >>>>> > >>>>> clang -c -g -gmacro -O0 -DM3=Value3 -include myfile2.h mainfile.c > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> AST > >>>>> > >>>>> ========================================================> >>>>> > >>>>> MacroDecl 0xd6c5c0 <<invalid sloc>> <invalid sloc> __llvm__ defined > >>>>> > >>>>> MacroDecl 0xd6c618 <<invalid sloc>> <invalid sloc> __clang__ defined > >>>>> > >>>>> > >>>>> > >>>>> … <More compiler macros> … > >>>>> > >>>>> > >>>>> > >>>>> MacroDecl 0x11c01b0 <<invalid sloc>> <invalid sloc> M3 defined > >>>>> > >>>>> FileIncludeDecl 0x11c0208 <mainfile.c:1:1> col:1 > >>>>> > >>>>> |-FileIncludeDecl 0x11c0238 <myfile2.h:1:1> col:1 > >>>>> > >>>>> | `-MacroDecl 0x11c0268 <<invalid sloc>> <invalid sloc> M4 defined > >>>>> > >>>>> |-MacroDecl 0x11c02c0 <mainfile.c:1:9> col:9 M1 defined > >>>>> > >>>>> |-FileIncludeDecl 0x11c0318 <myfile.h:1:1> col:1 > >>>>> > >>>>> | |-MacroDecl 0x11c0348 <line:4:8> col:8 M1 undefined > >>>>> > >>>>> | `-MacroDecl 0x11c03a0 <line:5:9> col:9 M1 defined > >>>>> > >>>>> `-MacroDecl 0x11c03f8 <mainfile.c:3:9> col:9 M2 defined > >>>>> > >>>>> TranslationUnitDecl 0xd6c078 <<invalid sloc>> <invalid sloc> > >>>>> > >>>>> |-TypedefDecl 0xd6c330 <<invalid sloc>> <invalid sloc> implicit > >>>>> __int128_t '__int128' > >>>>> > >>>>> |-TypedefDecl 0xd6c370 <<invalid sloc>> <invalid sloc> implicit > >>>>> __uint128_t 'unsigned __int128' > >>>>> > >>>>> |-TypedefDecl 0xd6c3c8 <<invalid sloc>> <invalid sloc> implicit > >>>>> __builtin_ms_va_list 'char *' > >>>>> > >>>>> `-TypedefDecl 0xd6c590 <<invalid sloc>> <invalid sloc> implicit > >>>>> __builtin_va_list 'struct __va_list_tag [1]' > >>>>> > >>>>> ========================================================> >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> LLVM IR > >>>>> > >>>>> ========================================================> >>>>> > >>>>> target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128" > >>>>> > >>>>> target triple = "x86_64-pc-linux" > >>>>> > >>>>> > >>>>> > >>>>> !llvm.dbg.cu = !{!0} > >>>>> > >>>>> !llvm.module.flags = !{!327} > >>>>> > >>>>> !llvm.ident = !{!328} > >>>>> > >>>>> > >>>>> > >>>>> !0 = distinct !DICompileUnit(language: DW_LANG_C99, file: !1, > >>>>> producer: "clang version 3.8.0 (trunk 251321)", isOptimized: false, > >>>>> runtimeVersion: 0, emissionKind: 1, enums: !2, macros: !3) > >>>>> > >>>>> !1 = !DIFile(filename: "mainfile.c", directory: "/") > >>>>> > >>>>> !2 = !{} > >>>>> > >>>>> !3 = !{!4, !5, … <More compiler macros> … , !312, !313} > >>>>> > >>>>> !4 = !DIMacro(macro type: DW_MACINFO_define, name: "__llvm__", value: > >>>>> !"1") > >>>>> > >>>>> !5 = !DIMacro(macro type: DW_MACINFO_define, name: "__clang__", > value: > >>>>> !"1") > >>>>> > >>>>> > >>>>> > >>>>> … <More compiler macros> … > >>>>> > >>>>> > >>>>> > >>>>> !312 = !DIMacro(macro type: DW_MACINFO_define, name: "M3", value: > >>>>> !"Value3") > >>>>> > >>>>> !313 = !DIFileInclude(file: !314, nodes: !315) > >>>>> > >>>>> !314 = !DIFile(filename: "mainfile.c", directory: "/") > >>>>> > >>>>> !315 = !{!316, !320, !321, !326} > >>>>> > >>>>> !316 = !DIFileInclude(file: !317, nodes: !318) > >>>>> > >>>>> !317 = !DIFile(filename: "myfile2.h", directory: "/") > >>>>> > >>>>> !318 = !{!319} > >>>>> > >>>>> !319 = !DIMacro(macro type: DW_MACINFO_define, name: "M4", value: > >>>>> !"Value4") > >>>>> > >>>>> !320 = !DIMacro(macro type: DW_MACINFO_define, name: "M1", line: 1, > >>>>> value: !"Value1") > >>>>> > >>>>> !321 = !DIFileInclude(line: 2, file: !322, nodes: !323) > >>>>> > >>>>> !322 = !DIFile(filename: "myfile.h", directory: "/") > >>>>> > >>>>> !323 = !{!324, !325} > >>>>> > >>>>> !324 = !DIMacro(macro type: DW_MACINFO_undef, name: "M1", line: 4) > >>>>> > >>>>> !325 = !DIMacro(macro type: DW_MACINFO_define, name: "M1", line: 5, > >>>>> value: !"NewValue1") > >>>>> > >>>>> !326 = !DIMacro(macro type: DW_MACINFO_define, name: "M2(x,y)", line: > >>>>> 3, value: !"( (x) + (y) * Value2)") > >>>>> > >>>>> !327 = !{i32 2, !"Debug Info Version", i32 3} > >>>>> > >>>>> !328 = !{!"clang version 3.8.0 (trunk 251321)"} > >>>>> > >>>>> ========================================================> >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> DWARF > >>>>> > >>>>> ========================================================> >>>>> > >>>>> Command line: llvm-dwarfdump.exe -debug-dump=macro mainfile.o > >>>>> > >>>>> > >>>>> > -------------------------------------------------------------------------------------- > >>>>> > >>>>> mainfile3.o: file format ELF64-x86-64 > >>>>> > >>>>> > >>>>> > >>>>> .debug_macinfo contents: > >>>>> > >>>>> DW_MACINFO_define - lineno: 0 macro: __llvm__ 1 > >>>>> > >>>>> DW_MACINFO_define - lineno: 0 macro: __clang__ 1 > >>>>> > >>>>> > >>>>> > >>>>> … <More compiler macros> … > >>>>> > >>>>> > >>>>> > >>>>> DW_MACINFO_define - lineno: 0 macro: M3 Value3 > >>>>> > >>>>> DW_MACINFO_start_file - lineno: 0 filenum: 1 > >>>>> > >>>>> DW_MACINFO_start_file - lineno: 0 filenum: 2 > >>>>> > >>>>> DW_MACINFO_define - lineno: 0 macro: M4 Value4 > >>>>> > >>>>> DW_MACINFO_end_file > >>>>> > >>>>> DW_MACINFO_define - lineno: 1 macro: M1 Value1 > >>>>> > >>>>> DW_MACINFO_start_file - lineno: 2 filenum: 3 > >>>>> > >>>>> DW_MACINFO_undef - lineno: 4 macro: M1 > >>>>> > >>>>> DW_MACINFO_define - lineno: 5 macro: M1 NewValue1 > >>>>> > >>>>> DW_MACINFO_end_file > >>>>> > >>>>> DW_MACINFO_define - lineno: 3 macro: M2(x,y) ( (x) + (y) * Value2) > >>>>> > >>>>> DW_MACINFO_end_file > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > -------------------------------------------------------------------------------------- > >>>>> > >>>>> Command line: llvm-dwarfdump.exe -debug-dump=line mainfile.o > >>>>> > >>>>> > >>>>> > -------------------------------------------------------------------------------------- > >>>>> > >>>>> .debug_line contents: > >>>>> > >>>>> > >>>>> > >>>>> … <Other line table Info> … > >>>>> > >>>>> > >>>>> > >>>>> Dir Mod Time File Len File Name > >>>>> > >>>>> ---- ---------- ---------- > --------------------------- > >>>>> > >>>>> file_names[ 1] 1 0x00000000 0x00000000 mainfile.c > >>>>> > >>>>> file_names[ 2] 1 0x00000000 0x00000000 myfile2.h > >>>>> > >>>>> file_names[ 3] 1 0x00000000 0x00000000 myfile.h > >>>>> > >>>>> ========================================================> >>>>> > >>>>> > >>>>> > >>>>> --------------------------------------------------------------------- > >>>>> Intel Israel (74) Limited > >>>>> > >>>>> This e-mail and any attachments may contain confidential material for > >>>>> the sole use of the intended recipient(s). Any review or distribution > >>>>> by others is strictly prohibited. If you are not the intended > >>>>> recipient, please contact the sender and delete all copies. > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> LLVM Developers mailing list > >>>>> llvm-dev at lists.llvm.org > >>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >>>>> > >>>>> > >>>>> > >>>>> --------------------------------------------------------------------- > >>>>> Intel Israel (74) Limited > >>>>> > >>>>> This e-mail and any attachments may contain confidential material for > >>>>> the sole use of the intended recipient(s). Any review or distribution > >>>>> by others is strictly prohibited. If you are not the intended > >>>>> recipient, please contact the sender and delete all copies. > >>>>> > >>>>> > >>>>> > >>>>> --------------------------------------------------------------------- > >>>>> Intel Israel (74) Limited > >>>>> > >>>>> This e-mail and any attachments may contain confidential material for > >>>>> the sole use of the intended recipient(s). Any review or distribution > >>>>> by others is strictly prohibited. If you are not the intended > >>>>> recipient, please contact the sender and delete all copies. > >>>>> > >>>>> --------------------------------------------------------------------- > >>>>> Intel Israel (74) Limited > >>>>> > >>>>> This e-mail and any attachments may contain confidential material for > >>>>> the sole use of the intended recipient(s). Any review or distribution > >>>>> by others is strictly prohibited. If you are not the intended > >>>>> recipient, please contact the sender and delete all copies. > >>>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> cfe-dev mailing list > >>>> cfe-dev at lists.llvm.org > >>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev > >>>> > >>>> > >>> > >> > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://lists.llvm.org/pipermail/llvm-dev/attachments/20151113/f1aac1e2/attachment.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > llvm-dev mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > ------------------------------ > > End of llvm-dev Digest, Vol 137, Issue 59 > ***************************************** >-- *Vivek Pandya* Mobile : +(91) 9408549393 Email: vivekvpandya at gmail.com Address: C - 33, Near Lakhubhai Hall, Kalvibeed, Bhavnagar, Gujarat, India - 364002. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151114/36616aba/attachment-0001.html>