search for: mdcompileunit

...blaikie at gmail.com> wrote: > On Mon, Mar 23, 2015 at 8:15 AM, Khilan Gudka <Khilan.Gudka at cl.cam.ac.uk> > wrote: > >> Hi David >> >> Thanks for your email. >> >> What's the benefit/purpose of the MDLLVMModule over just having the >>> MDCompileUnits themselves? I would imagine the user cares about which >>> source file the problem was in (obtained from the MDCompileUnit), not the >>> sequence of BC modules that may've been built into? >>> >> >> We envisage it to be useful when an analysis tool built...

Hi David Thanks for your email. What's the benefit/purpose of the MDLLVMModule over just having the > MDCompileUnits themselves? I would imagine the user cares about which > source file the problem was in (obtained from the MDCompileUnit), not the > sequence of BC modules that may've been built into? > We envisage it to be useful when an analysis tool built using LLVM needs to know which MDCompileU...

...ute to this LLVM module (i.e. that are not part of an LLVM submodule) The format of the metadata looks like this: !llvm.module = !{!0} !0 = !MDLLVMModule(name: "test123.bc", modules: !1, cus: !24) !1 = !{!2} !2 = !MDLLVMModule(name: "test12.bc", cus: !3) !3 = !{!4, !18} !4 = !MDCompileUnit(... filename: "test1.c" ...) !18 = !MDCompileUnit(... filename: "test2.c" ...) !24 = !{!25} !25 = !MDCompileUnit(... filename: "test3.c" ...) Each linked LLVM module has the named metadata node "llvm.module" that points to its own MDLLVMModule node. In this...

...> CompileUnit" map. That highlights a problem that my proposal doesn't solve on its own. While this proposal creates a "Function -> Subprogram" map, there still isn't a "Subprogram -> CompileUnit" map -- that would still (for now) be stored implicitly via `MDCompileUnit::getSubprograms()`. Why isn't this map encoded in the `scope:` chain? Because many of the `scope:` chains currently terminate at `MDFile`s or `null` instead of `MDCompileUnit`s. Why? Because LTO type uniquing needs scope chains to be identical. (I have a vague plan for fixing this, too: (1...

.... > > That highlights a problem that my proposal doesn't solve on its own. > While this proposal creates a "Function -> Subprogram" map, there still > isn't a "Subprogram -> CompileUnit" map -- that would still (for now) > be stored implicitly via `MDCompileUnit::getSubprograms()`. > > I guess this is (also?) what I was thinking about. > > Why isn't this map encoded in the `scope:` chain? Because many of the > `scope:` chains currently terminate at `MDFile`s or `null` instead of > `MDCompileUnit`s. Why? Because LTO type uniquing...

...p. > > That highlights a problem that my proposal doesn't solve on its own. > While this proposal creates a "Function -> Subprogram" map, there still > isn't a "Subprogram -> CompileUnit" map -- that would still (for now) > be stored implicitly via `MDCompileUnit::getSubprograms()`. > > Why isn't this map encoded in the `scope:` chain? Because many of the > `scope:` chains currently terminate at `MDFile`s or `null` instead of > `MDCompileUnit`s. Why? Because LTO type uniquing needs scope chains > to be identical. (I have a vague plan...

...t; >> This syntax pulls the tag out of the current header-string, calls >> the rest of the header "fields", and includes the metadata operands >> in "operands". >> >> 5. Incrementally create subclasses of `DebugMDNode`, such as >> `MDCompileUnit` and `MDSubprogram`. Sub-classed nodes replace the >> "fields" and "operands" catch-alls with explicit names for each >> operand. >> >> Proposed assembly syntax: >> >> !7 = metadata !MDSubprogram(line: 45, name: "foo&quot...

...handle: i32* @global_var) This syntax pulls the tag out of the current header-string, calls the rest of the header "fields", and includes the metadata operands in "operands". 5. Incrementally create subclasses of `DebugMDNode`, such as `MDCompileUnit` and `MDSubprogram`. Sub-classed nodes replace the "fields" and "operands" catch-alls with explicit names for each operand. Proposed assembly syntax: !7 = metadata !MDSubprogram(line: 45, name: "foo", displayName: "foo",...

...lls the tag out of the current header-string, calls > >> the rest of the header "fields", and includes the metadata operands > >> in "operands". > >> > >> 5. Incrementally create subclasses of `DebugMDNode`, such as > >> `MDCompileUnit` and `MDSubprogram`. Sub-classed nodes replace the > >> "fields" and "operands" catch-alls with explicit names for each > >> operand. > >> > >> Proposed assembly syntax: > >> > >> !7 = metadata !MDSubprog...

...32* @global_var) > > This syntax pulls the tag out of the current header-string, calls > the rest of the header "fields", and includes the metadata operands > in "operands". > > 5. Incrementally create subclasses of `DebugMDNode`, such as > `MDCompileUnit` and `MDSubprogram`. Sub-classed nodes replace the > "fields" and "operands" catch-alls with explicit names for each > operand. > > Proposed assembly syntax: > > !7 = metadata !MDSubprogram(line: 45, name: "foo", displayName: >...

I'm getting close to executing the transition to the new debug info hierarchy. For reference, I've attached two WIP patches (which would be squashed before commit) and the WIP upgrade script I'm using. - transition-code.patch: Change the `DIDescriptor` hierarchy to lightweight wrappers around the subclasses of `DebugNode` (instead of rather heavier wrappers around