[LLVMdev] using -debug-ir to map identify IR mapping

[David Blaikie]

+Daniel Malea, so he knows this is currently broken.

On Wed, Oct 15, 2014 at 9:52 AM, Adrian Prantl <aprantl at apple.com> wrote:

> Could I interest you in contributing a patch that fixes this for
> -debug-ir? Maybe even with the DIBuilder interface David mentioned? :-)
>
> -- adrian
>
> On Oct 15, 2014, at 9:51 AM, Muneeb Khan <muneeb.khan at it.uu.se> wrote:
>
> Adding the flags in an opt pass seems to do the trick. I added the flags
> as follows
>
> M.addModuleFlag(llvm::Module::Warning, "Dwarf Version", 3);
>
> M.addModuleFlag(llvm::Module::Error, "Debug Info Version",
>                              llvm::DEBUG_METADATA_VERSION);
>
> llvm-dwarfdump and addr2line now point at a line in .ll files, not the
> source files.
>
> Thanks!
>
> /Muneeb
>
> On 15 Oct 2014, at 18:22, David Blaikie <dblaikie at gmail.com> wrote:
>
> (similarly for the dwarf version flag)
>
> On Wed, Oct 15, 2014 at 9:22 AM, David Blaikie <dblaikie at gmail.com> wrote:
>
>>
>>
>> On Wed, Oct 15, 2014 at 9:04 AM, Adrian Prantl <aprantl at apple.com> wrote:
>>
>>> I have no experience with debug-ir, but is it possible that the debug-ir
>>> pass never sets the debug info version? There should be a named metadata
>>> node
>>>   !llvm.module.flags = !{..., !123}
>>>   !123 = metadata !{i32 1, metadata !"Debug Info Version", i32 2}
>>> in the .ll output. If it is missing, just have a look at the clang
>>> sources for an example how to add a module flag.
>>>
>>
>> Perhaps this should be built into DIBuilder, but I'm not sure.
>>
>> Yeah, looking at how it's implemented, this isn't ideal - we've got the
>> string "Debug Info Version" written in Clang and in LLVM, not using a
>> shared constant or common utility functions owned in the same place. This
>> should probably be part of DIBuilder in some way or another so that clients
>> don't have to duplicate this string, etc.
>>
>> - David
>>
>>
>>>
>>> -- adrian
>>>
>>>
>>> On Oct 15, 2014, at 8:20 AM, Muneeb Khan <muneeb.khan at it.uu.se> wrote:
>>>
>>> Yes, I am using opt and llc from the same version (3.5).
>>> I know that there were issues with debug-ir in 3.4. I have explored the
>>> source tree myself for 3.5 and I know that the pass -debug-ir does kick in
>>> with opt.
>>> But I have no clue of what happens with the debug information in (and
>>> after) the llc pass.
>>>
>>> /Muneeb
>>>
>>> On 15 Oct 2014, at 17:14, David Blaikie <dblaikie at gmail.com> wrote:
>>>
>>>
>>>
>>> On Wed, Oct 15, 2014 at 7:08 AM, Muneeb Khan <muneeb.khan at it.uu.se>
>>> wrote:
>>>
>>>> Hi,
>>>> I am using the -debug-ir pass in LLVM-3.5 opt tool to map binary
>>>> information back to the IR instead of the source files.
>>>> I use the opt tool to  generate a .ll file. But when I run the llc tool
>>>> on it to generate an assembly (or object) file, it gives me the following
>>>> warning
>>>>
>>>> warning: ignoring debug info with an invalid version (0) in
>>>>
>>>
>>> Are you using opt and llc from the same LLVM version? (mixing and
>>> matching could produce this problem)
>>>
>>> Or possibly debug-ir was never updated to produce the dubug info version
>>> - Adrian?
>>>
>>>
>>>>
>>>> How can I use the debug-ir functionality to achieve a mapping from the
>>>> binary to the IR?
>>>> Thanks!
>>>>
>>>> Muneeb Khan
>>>> PhD student
>>>> Department of Information Technology,
>>>> Uppsala University,
>>>> Sweden
>>>> Tel: +46 18 - 471 1049
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> LLVM Developers mailing list
>>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>>
>>>>
>>>
>>>
>>> Muneeb Khan
>>> PhD student
>>> Department of Information Technology,
>>> Uppsala University,
>>> Sweden
>>> Tel: +46 18 - 471 1049
>>>
>>>
>>>
>>>
>>>
>>
>
>
> Muneeb Khan
> PhD student
> Department of Information Technology,
> Uppsala University,
> Sweden
> Tel: +46 18 - 471 1049
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141015/d2e68b92/attachment.html>