[LLVMdev] More DIFactory questions - still stumped

[Talin]

On Sun, Oct 10, 2010 at 9:54 AM, Talin <viridia at gmail.com> wrote:

> BTW, the reason I stopped responding to this thread is not because I solved
> the problem, but because I simply gave up and decided to work on other
> things for a while since I was making no progress. Having finished those
> other things (the stack crawler, for one), I'm hoping that time and a fresh
> start will yield better results. Unfortunately after about a day spent
> reviewing old llvm-dev threads and trying different permutations of calls to
> DIFactory, I have not discovered anything that I didn't already know.
>
> With respect to the suggestion of building my own copy of dwarfdump (so
> that I could run it under gdb and see where it breaks), I never did get it
> to compile and run on OS X, since it requires ELF headers and libs. I
> thought about doing the same thing under Linux, however dwarfdump doesn't
> segfault on Linux when I feed it my LLVM-generated binary. (It does report
> errors, however: "dwarf_srclines: DW_DLE_ATTR_FORM_BAD". The weird part is
> that it does this even when I completely disable the code that calls
> IRBuilder.SetCurrentDebugLocation()).
>

Interestingly enough, I just upgraded to the latest Ubuntu (10.10 - Maverick
Meercat), and the LLVM-generated code no longer builds: I get the following
error in the assembler stage (after the bitcode is converted to assembly):

   SwitchStmtTest.s: Assembler messages:
   SwitchStmtTest.s:294899: Fatal error: duplicate .debug_line sections

Note that this is still with calls to IRBuilder.SetCurrentDebugLocation()
disabled - My FE is not emitting any debug line information at all at this
time.


> As per usual, this is with a recent LLVM head (like about a week old).
>
> On Tue, Sep 7, 2010 at 9:21 AM, Devang Patel <dpatel at apple.com> wrote:
>
>>
>> On Sep 7, 2010, at 9:11 AM, Renato Golin wrote:
>>
>> On 7 September 2010 16:49, Devang Patel <dpatel at apple.com> wrote:
>>
>> Your recent changes mentioned below would change correctness of debug
>> info,
>>
>> but it would unlikely to impact structure of DWARF generated. And somehow,
>>
>> this structure is invalid in your case.
>>
>>
>> I was hoping for a quick-fix on the assumptions of DwarfDebug about
>> Subprograms' MDNodes, but it might be anywhere.
>>
>> Reducing the test case is the best solution, but it might not be easy.
>>
>> Validating the MDNodes in DIFactory (or anywhere before DwarfDebug)
>> would be a good step to ensure IR consistency and isolate problems.
>> Unfortunately, it is the kind of thing that is not fundamental to get
>> things working, so it always gets left behind... ;)
>>
>>
>> I understand your point and certainly acknowledge need for better
>> documentation.
>>
>> There are couple of wrinkles to note here
>> - While constructing IR using DIFactory you are not seeing entire picture.
>> When you see a declaration you're not sure whether you'll see matching def.
>> or not. When you build a inlined subprogram, you don't know whether you'll
>> see a out of line definition of this function or not. etc...
>> - DwarfDebug must be able to handle malformed debug info gracefully and
>> make best out of whatever is fed. This is because, optimizer may have chewed
>> on IR mercilessly and optimizer must not be influenced by presence of
>> encoded debug info in IR.
>>
>> -
>> Devang
>>
>
>
>
> --
> -- Talin
>



-- 
-- Talin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20101010/83db9c7e/attachment.html>