On Oct 10, 2010, at 7:21 PM, Talin <viridia at gmail.com> wrote:
> 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
>
This is a known Linux binutils bug. There is a llvm pr in bugzilla database, I
don't remember the no. though.
-
Devang> 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/20101011/4f3b3309/attachment.html>