[LLVMdev] More DIFactory questions - still stumped

[Talin]

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()).

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20101010/6f4b961e/attachment.html>