Internal API Changes

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Internal API Changes

Irina Lipov
Hi,
I saw your update regarding "The DIBuilder interface used by front ends to encode debugging information in the LLVM IR now expects clients to use DIBuilder::finalize() at the end of translation unit to complete debugging information encoding"
Does it mean that in the new version you defer emission of some debug info until  the translation  is finished and this is a reason to use DIBuilder::finilize?

--
Thank you in advance,
Irena

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Internal API Changes

Irina Lipov

Hi,
I saw your update regarding "The DIBuilder interface used by front ends to encode debugging information in the LLVM IR now expects clients to use DIBuilder::finalize() at the end of translation unit to complete debugging information encoding"
Does it mean that in the new version you defer emission of some debug info until  the translation  is finished and this is a reason to use DIBuilder::finilize?

--
Thank you in advance,
Irena



--
Best,
Irena

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Internal API Changes

Devang Patel
In reply to this post by Irina Lipov

On Aug 22, 2011, at 6:48 AM, Irina Lipov wrote:

Hi,
I saw your update regarding "The DIBuilder interface used by front ends to encode debugging information in the LLVM IR now expects clients to use DIBuilder::finalize() at the end of translation unit to complete debugging information encoding"
Does it mean that in the new version you defer emission of some debug info until  the translation  is finished and this is a reason to use DIBuilder::finalize?

Before this change, each type, subprogram and global variable information used to refer compile unit directly. Now, the compile unit keeps track of all these info directly. The compile unit MDNode is updated in the ::finalize() with list of types, subprograms etc..
-
Devang


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Internal API Changes

Talin-3
So, I just sync'd to LLVM tip and added the call to DIBuilder::finalize(). But even with that change I am getting an error when I try to run llc:

Assertion failed: (TheCU && "Unable to find compile unit!"), function endFunction, file /Users/talin/Projects/llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp, line 1306.

And looking at the .bc dissassembly, I see there are indeed compile unit MDNodes, although at this level I can't tell if they are hooked up correctly.

On Wed, Aug 31, 2011 at 9:07 AM, Devang Patel <[hidden email]> wrote:


On Aug 22, 2011, at 6:48 AM, Irina Lipov wrote:

Hi,
I saw your update regarding "The DIBuilder interface used by front ends to encode debugging information in the LLVM IR now expects clients to use DIBuilder::finalize() at the end of translation unit to complete debugging information encoding"
Does it mean that in the new version you defer emission of some debug info until  the translation  is finished and this is a reason to use DIBuilder::finalize?

Before this change, each type, subprogram and global variable information used to refer compile unit directly. Now, the compile unit keeps track of all these info directly. The compile unit MDNode is updated in the ::finalize() with list of types, subprograms etc..
-
Devang


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


--
-- Talin

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Internal API Changes

Duncan Sands
Hi Talin,

> So, I just sync'd to LLVM tip and added the call to DIBuilder::finalize(). But
> even with that change I am getting an error when I try to run llc:
>
> Assertion failed: (TheCU && "Unable to find compile unit!"), function
> endFunction, file
> /Users/talin/Projects/llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp, line 1306.
>
> And looking at the .bc dissassembly, I see there are indeed compile unit
> MDNodes, although at this level I can't tell if they are hooked up correctly.

you might want to take a look at this llvm-gcc commit:

r137753 | dpatel | 2011-08-16 23:03:26 +0200 (Tue, 16 Aug 2011) | 3 lines

DIBuilder is moving forward to reduce in memory use by MDNodes. However,
DIFactory does not emit debug info in updated form.
Use LLVMDebugVersion10 directly here so that debug info nodes produced by
DIFactory do not claim to adhere newer structure.

Ciao, Duncan.

>
> On Wed, Aug 31, 2011 at 9:07 AM, Devang Patel <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>
>     On Aug 22, 2011, at 6:48 AM, Irina Lipov wrote:
>
>>     Hi,
>>     I saw your update regarding "/The |DIBuilder| interface used by front ends
>>     to encode debugging information in the LLVM IR now expects clients to use
>>     |DIBuilder::finalize()| at the end of translation unit to complete
>>     debugging information encoding"/
>>     Does it mean that in the new version you defer emission of some debug
>>     info until  the translation  is finished and this is a reason to use
>>     DIBuilder::finalize?
>
>     Before this change, each type, subprogram and global variable information
>     used to refer compile unit directly. Now, the compile unit keeps track of
>     all these info directly. The compile unit MDNode is updated in the
>     ::finalize() with list of types, subprograms etc..
>     -
>     Devang
>
>
>     _______________________________________________
>     LLVM Developers mailing list
>     [hidden email] <mailto:[hidden email]> http://llvm.cs.uiuc.edu
>     http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
> --
> -- Talin
>
>
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Internal API Changes

Talin-3
On Sun, Sep 4, 2011 at 11:38 PM, Duncan Sands <[hidden email]> wrote:
Hi Talin,

> So, I just sync'd to LLVM tip and added the call to DIBuilder::finalize(). But
> even with that change I am getting an error when I try to run llc:
>
> Assertion failed: (TheCU && "Unable to find compile unit!"), function
> endFunction, file
> /Users/talin/Projects/llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp, line 1306.
>
> And looking at the .bc dissassembly, I see there are indeed compile unit
> MDNodes, although at this level I can't tell if they are hooked up correctly.

you might want to take a look at this llvm-gcc commit:

r137753 | dpatel | 2011-08-16 23:03:26 +0200 (Tue, 16 Aug 2011) | 3 lines

DIBuilder is moving forward to reduce in memory use by MDNodes. However,
DIFactory does not emit debug info in updated form.
Use LLVMDebugVersion10 directly here so that debug info nodes produced by
DIFactory do not claim to adhere newer structure.

I'm not sure I understand. I'm using DIBuilder, not DIFactory, since I thought DIFactory was deprecated.
 
Ciao, Duncan.

>
> On Wed, Aug 31, 2011 at 9:07 AM, Devang Patel <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>
>     On Aug 22, 2011, at 6:48 AM, Irina Lipov wrote:
>
>>     Hi,
>>     I saw your update regarding "/The |DIBuilder| interface used by front ends
>>     to encode debugging information in the LLVM IR now expects clients to use
>>     |DIBuilder::finalize()| at the end of translation unit to complete
>>     debugging information encoding"/
>>     Does it mean that in the new version you defer emission of some debug
>>     info until  the translation  is finished and this is a reason to use
>>     DIBuilder::finalize?
>
>     Before this change, each type, subprogram and global variable information
>     used to refer compile unit directly. Now, the compile unit keeps track of
>     all these info directly. The compile unit MDNode is updated in the
>     ::finalize() with list of types, subprograms etc..
>     -
>     Devang
>
>
>     _______________________________________________
>     LLVM Developers mailing list
>     [hidden email] <mailto:[hidden email]> http://llvm.cs.uiuc.edu
>     http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
> --
> -- Talin
>
>
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev



--
-- Talin

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Internal API Changes

Duncan Sands
Hi Talin, I mentioned it because the error message you are getting is
identical (IIRC) to the error message being produced by llvm-gcc before
this patch went in.

Ciao, Duncan.

On 05/09/11 11:21, Talin wrote:

> On Sun, Sep 4, 2011 at 11:38 PM, Duncan Sands <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Hi Talin,
>
>      > So, I just sync'd to LLVM tip and added the call to
>     DIBuilder::finalize(). But
>      > even with that change I am getting an error when I try to run llc:
>      >
>      > Assertion failed: (TheCU && "Unable to find compile unit!"), function
>      > endFunction, file
>      > /Users/talin/Projects/llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp, line 1306.
>      >
>      > And looking at the .bc dissassembly, I see there are indeed compile unit
>      > MDNodes, although at this level I can't tell if they are hooked up correctly.
>
>     you might want to take a look at this llvm-gcc commit:
>
>     r137753 | dpatel | 2011-08-16 23:03:26 +0200 (Tue, 16 Aug 2011) | 3 lines
>
>     DIBuilder is moving forward to reduce in memory use by MDNodes. However,
>     DIFactory does not emit debug info in updated form.
>     Use LLVMDebugVersion10 directly here so that debug info nodes produced by
>     DIFactory do not claim to adhere newer structure.
>
> I'm not sure I understand. I'm using DIBuilder, not DIFactory, since I thought
> DIFactory was deprecated.
>
>     Ciao, Duncan.
>
>      >
>      > On Wed, Aug 31, 2011 at 9:07 AM, Devang Patel <[hidden email]
>     <mailto:[hidden email]>
>      > <mailto:[hidden email] <mailto:[hidden email]>>> wrote:
>      >
>      >
>      >     On Aug 22, 2011, at 6:48 AM, Irina Lipov wrote:
>      >
>      >>     Hi,
>      >>     I saw your update regarding "/The |DIBuilder| interface used by
>     front ends
>      >>     to encode debugging information in the LLVM IR now expects clients
>     to use
>      >>     |DIBuilder::finalize()| at the end of translation unit to complete
>      >>     debugging information encoding"/
>      >>     Does it mean that in the new version you defer emission of some debug
>      >>     info until  the translation  is finished and this is a reason to use
>      >>     DIBuilder::finalize?
>      >
>      >     Before this change, each type, subprogram and global variable information
>      >     used to refer compile unit directly. Now, the compile unit keeps track of
>      >     all these info directly. The compile unit MDNode is updated in the
>      >     ::finalize() with list of types, subprograms etc..
>      >     -
>      >     Devang
>      >
>      >
>      >     _______________________________________________
>      >     LLVM Developers mailing list
>      > [hidden email] <mailto:[hidden email]>
>     <mailto:[hidden email] <mailto:[hidden email]>>
>     http://llvm.cs.uiuc.edu
>      > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>      >
>      >
>      > --
>      > -- Talin
>      >
>      >
>      > _______________________________________________
>      > LLVM Developers mailing list
>      > [hidden email] <mailto:[hidden email]> http://llvm.cs.uiuc.edu
>      > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>     _______________________________________________
>     LLVM Developers mailing list
>     [hidden email] <mailto:[hidden email]> http://llvm.cs.uiuc.edu
>     http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
>
>
> --
> -- Talin

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Internal API Changes

Devang Patel
Yup. Now, the debug info nodes do not refer to compile unit.
-
Devang
On Sep 5, 2011, at 2:23 AM, Duncan Sands wrote:

> Hi Talin, I mentioned it because the error message you are getting is
> identical (IIRC) to the error message being produced by llvm-gcc before
> this patch went in.
>
> Ciao, Duncan.
>
> On 05/09/11 11:21, Talin wrote:
>> On Sun, Sep 4, 2011 at 11:38 PM, Duncan Sands <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>>    Hi Talin,
>>
>>> So, I just sync'd to LLVM tip and added the call to
>>    DIBuilder::finalize(). But
>>> even with that change I am getting an error when I try to run llc:
>>>
>>> Assertion failed: (TheCU && "Unable to find compile unit!"), function
>>> endFunction, file
>>> /Users/talin/Projects/llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp, line 1306.
>>>
>>> And looking at the .bc dissassembly, I see there are indeed compile unit
>>> MDNodes, although at this level I can't tell if they are hooked up correctly.
>>
>>    you might want to take a look at this llvm-gcc commit:
>>
>>    r137753 | dpatel | 2011-08-16 23:03:26 +0200 (Tue, 16 Aug 2011) | 3 lines
>>
>>    DIBuilder is moving forward to reduce in memory use by MDNodes. However,
>>    DIFactory does not emit debug info in updated form.
>>    Use LLVMDebugVersion10 directly here so that debug info nodes produced by
>>    DIFactory do not claim to adhere newer structure.
>>
>> I'm not sure I understand. I'm using DIBuilder, not DIFactory, since I thought
>> DIFactory was deprecated.
>>
>>    Ciao, Duncan.
>>
>>>
>>> On Wed, Aug 31, 2011 at 9:07 AM, Devang Patel <[hidden email]
>>    <mailto:[hidden email]>
>>> <mailto:[hidden email] <mailto:[hidden email]>>> wrote:
>>>
>>>
>>>    On Aug 22, 2011, at 6:48 AM, Irina Lipov wrote:
>>>
>>>>    Hi,
>>>>    I saw your update regarding "/The |DIBuilder| interface used by
>>    front ends
>>>>    to encode debugging information in the LLVM IR now expects clients
>>    to use
>>>>    |DIBuilder::finalize()| at the end of translation unit to complete
>>>>    debugging information encoding"/
>>>>    Does it mean that in the new version you defer emission of some debug
>>>>    info until  the translation  is finished and this is a reason to use
>>>>    DIBuilder::finalize?
>>>
>>>    Before this change, each type, subprogram and global variable information
>>>    used to refer compile unit directly. Now, the compile unit keeps track of
>>>    all these info directly. The compile unit MDNode is updated in the
>>>    ::finalize() with list of types, subprograms etc..
>>>    -
>>>    Devang
>>>
>>>
>>>    _______________________________________________
>>>    LLVM Developers mailing list
>>> [hidden email] <mailto:[hidden email]>
>>    <mailto:[hidden email] <mailto:[hidden email]>>
>>    http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>
>>>
>>> --
>>> -- Talin
>>>
>>>
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> [hidden email] <mailto:[hidden email]> http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>>    _______________________________________________
>>    LLVM Developers mailing list
>>    [hidden email] <mailto:[hidden email]> http://llvm.cs.uiuc.edu
>>    http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>>
>>
>>
>> --
>> -- Talin
>
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Internal API Changes

Talin-3
Well, for now I've disabled generating debug info in my frontend so that I can get work done, but I'd like to know what the problem is. I am calling finalize().

On Tue, Sep 6, 2011 at 9:24 AM, Devang Patel <[hidden email]> wrote:
Yup. Now, the debug info nodes do not refer to compile unit.
-
Devang
On Sep 5, 2011, at 2:23 AM, Duncan Sands wrote:

> Hi Talin, I mentioned it because the error message you are getting is
> identical (IIRC) to the error message being produced by llvm-gcc before
> this patch went in.
>
> Ciao, Duncan.
>
> On 05/09/11 11:21, Talin wrote:
>> On Sun, Sep 4, 2011 at 11:38 PM, Duncan Sands <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>>    Hi Talin,
>>
>>> So, I just sync'd to LLVM tip and added the call to
>>    DIBuilder::finalize(). But
>>> even with that change I am getting an error when I try to run llc:
>>>
>>> Assertion failed: (TheCU && "Unable to find compile unit!"), function
>>> endFunction, file
>>> /Users/talin/Projects/llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp, line 1306.
>>>
>>> And looking at the .bc dissassembly, I see there are indeed compile unit
>>> MDNodes, although at this level I can't tell if they are hooked up correctly.
>>
>>    you might want to take a look at this llvm-gcc commit:
>>
>>    r137753 | dpatel | 2011-08-16 23:03:26 +0200 (Tue, 16 Aug 2011) | 3 lines
>>
>>    DIBuilder is moving forward to reduce in memory use by MDNodes. However,
>>    DIFactory does not emit debug info in updated form.
>>    Use LLVMDebugVersion10 directly here so that debug info nodes produced by
>>    DIFactory do not claim to adhere newer structure.
>>
>> I'm not sure I understand. I'm using DIBuilder, not DIFactory, since I thought
>> DIFactory was deprecated.
>>
>>    Ciao, Duncan.
>>
>>>
>>> On Wed, Aug 31, 2011 at 9:07 AM, Devang Patel <[hidden email]
>>    <mailto:[hidden email]>
>>> <mailto:[hidden email] <mailto:[hidden email]>>> wrote:
>>>
>>>
>>>    On Aug 22, 2011, at 6:48 AM, Irina Lipov wrote:
>>>
>>>>    Hi,
>>>>    I saw your update regarding "/The |DIBuilder| interface used by
>>    front ends
>>>>    to encode debugging information in the LLVM IR now expects clients
>>    to use
>>>>    |DIBuilder::finalize()| at the end of translation unit to complete
>>>>    debugging information encoding"/
>>>>    Does it mean that in the new version you defer emission of some debug
>>>>    info until  the translation  is finished and this is a reason to use
>>>>    DIBuilder::finalize?
>>>
>>>    Before this change, each type, subprogram and global variable information
>>>    used to refer compile unit directly. Now, the compile unit keeps track of
>>>    all these info directly. The compile unit MDNode is updated in the
>>>    ::finalize() with list of types, subprograms etc..
>>>    -
>>>    Devang
>>>
>>>
>>>    _______________________________________________
>>>    LLVM Developers mailing list
>>> [hidden email] <mailto:[hidden email]>
>>    <mailto:[hidden email] <mailto:[hidden email]>>
>>    http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>
>>>
>>> --
>>> -- Talin
>>>
>>>
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> [hidden email] <mailto:[hidden email]> http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>>    _______________________________________________
>>    LLVM Developers mailing list
>>    [hidden email] <mailto:[hidden email]> http://llvm.cs.uiuc.edu
>>    http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>>
>>
>>
>> --
>> -- Talin
>
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]         http://llvm.cs.uiuc.edu



--
-- Talin

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev