[llvm-dev] llvm-dev Digest, Vol 137, Issue 59
vivek pandya via llvm-dev
llvm-dev at lists.llvm.org
Fri Nov 13 23:42:10 PST 2015
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>
More information about the llvm-dev
mailing list