Added DI macro creation API to DIBuilder.
This API will be used by Clang to create the DIMacro and DIMacroFile metadata entities.
Note: Usage of these new interface functions can be found in D16135.
Differential D16077
DIBuilder support DI Macro creation aaboud on Jan 11 2016, 1:03 PM. Authored by
Details Added DI macro creation API to DIBuilder. Note: Usage of these new interface functions can be found in D16135.
Diff Detail
Event Timeline
Comment Actions Applied changes according to Adrian comment.
Comment Actions IIRC DIBuilder has a couple of unit tests (unittests/IR/IRBuilderTest.cpp). Could you add tests for the new functionality?
Comment Actions Added unit test that covers the macro new DIBuilder create API. Comment Actions Just one final question: Why is replaceArrays() necessary? We need it for DICompositeType because composite types may be recursive. Is that also the case for DIMacroNodeArray? Comment Actions The reason why DIMacroFile need the replaceArrays() function is that when we create the DIMacroFile, we still do not have the list of children nodes of that DIE. If I understand your concern well, you are suggesting that instead of the "replaceArrays()" function, we implement a "DIMacroFile::replaceMacros()" similar to the function of the DICompileUnit, correct? Comment Actions Updated patch to top of trunk (r276746) - Thanks to Ranjeet Singh. Please, provide your feedback. Comment Actions Yes, I think putting it on DIMacroFile might be a better interface, but I'm not sure. Comment Actions After short investigation there is an issue with both options.
t.h #ifdef A #define Y X #else #define Y Z #endif t1.h #define A #include "t.h" #undef A t2.h #define B #include "t.h" #undef B t.c #include "t1.h" #include "t2.h" In this case the LLVM IR for "t.h" will look like this: !306 = !DIMacroFile(line: 2, file: !307, nodes: !308) !307 = !DIFile(filename: "t.h", directory: "/") !308 = !{!309, !310} !309 = !DIMacro(type: DW_MACINFO_define, line: 2, name: "Y", value: "X") !310 = !DIMacro(type: DW_MACINFO_define, line: 4, name: "Y", value: "Z") Even though in this case the include of "t.h" from "t1.h" does not match the include of "t.h" from "t2.h", but because when we created the DIMacroFile we created it with empty nodes, there was a match (same macro tag, same line number, same file name, same empty node list). So, if you ask me, I still prefer to use unique on Macro nodes, however we need to create them with the nodes and prevent changing them later. Comment Actions This doesn't look too bad to me, but maybe I'm not seeing the whole picture: The bulk of the nodes will be DIMacro nodes and if I understand correctly they are leaf nodes and can safely be created non-distinct and shareable immediately. For the DIMacroFiles, we could create them as temporary distinct nodes first — similar to DIBuilder::createReplaceableCompositeType() and then replace them with non-distinct nodes once the lists are finalized. Comment Actions Sorry, for the delay, I was in an extended vacation. Again, sorry for the delay. Regards, Comment Actions No worries, I was mostly concerned that this might have been blocked on waiting for feedback from myself.
Comment Actions Thanks Adrian for the comments, I will do the changes as needed and upload a new patch.
Comment Actions Thanks! LGTM with outstanding comments addressed.
|