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