[llvm-commits] [PATCH] Fix emission of debug data for global variables

James Molloy james.molloy at arm.com
Mon Sep 26 10:35:23 PDT 2011


I agree with everything said. Because it goes to asm (even though the asm
isn't checked), the target triple is needed, and as I have to choose a
target triple, X86 was the obvious choice (I also put it in the X86
directory) 

Llvm-dwarfdump would be much nicer :)

Committing now. Thanks for the review!

James

-----Original Message-----
From: Eric Christopher [mailto:echristo at apple.com] 
Sent: 26 September 2011 18:28
To: James Molloy
Cc: 'Devang Patel'; Commit Messages and Patches for LLVM
Subject: Re: [llvm-commits] [PATCH] Fix emission of debug data for global
variables

Can't think of a reason it's x86 specific.

That said you could also use 'llc %s -mtriple=i686-pc-linux-gnu' or
something similar if I'm wrong and it is. In that case if you could put it
in test/DebugInfo/X86 :)

-eric

On Sep 26, 2011, at 10:20 AM, James Molloy wrote:

> Hi Devang,
> 
> Thanks. As the testcase needs to compile down to assembly (to test the
DWARF
> output), is the target triple really unnecessary?
> 
> Cheers,
> 
> James
> 
> -----Original Message-----
> From: Devang Patel [mailto:dpatel at apple.com] 
> Sent: 26 September 2011 18:19
> To: James Molloy
> Cc: Commit Messages and Patches for LLVM
> Subject: Re: [llvm-commits] [PATCH] Fix emission of debug data for global
> variables
> 
> James,
> 
> Your patch looks good. Please apply (remove target datalayout and target
> triple from the test case because it is unnecessary).
> Thanks!
> -
> Devang
> On Sep 26, 2011, at 9:03 AM, James Molloy wrote:
> 
>> Hi,
>> 
>> With the new debug information changes, global variables aren't emitted
> properly to DWARF. The DW_AT_decl_file field is incorrect.
>> 
>> This stems from DwarfCompileUnit.cpp:138:
>> 
>> unsigned FileID = DD->GetOrCreateSourceID(G.getContext().getFilename(),
>>                                           G.getContext().getDirectory());
>> 
>> G.getContext() returns a NULL metadatum for the new metadata format (it
> used to return the CompileUnit). This causes a new SourceID to be
generated
> for the "null" file, and the global is assigned this incorrect SourceID.
>> 
>> Attached is a testcase and proposed patch. It inlines getFilename() and
> getDirectory() into DIGlobalVariable, returning the original
> getContext().getFilename() for old versions of the debug info and
> getFieldAs<DIFile>(6).getFilename() for new versions.
>> 
>> I've implemented it this way so that the old code path is identical to
> before. I'm not sure if this is the most perfect fix - as
> getFieldAs<DIFile>(6) is valid (seemingly) for all debug info versions,
> perhaps the best idea would be to remove the conditionalization and always
> return getFieldAs<DIFile>(6).getFilename/getDirectory() ?
>> 
>> 
>> Cheers,
>> 
>> James
>> 
>> 
>> -- IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium.  Thank
>
you.<2011-09-26-GlobalVarContext.patch>_____________________________________
> __________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits









More information about the llvm-commits mailing list