[LLVMbugs] [Bug 12942] New: debug_info of compile_units with same filename + dirname clash / duplicate labels

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=12942

             Bug #: 12942
           Summary: debug_info of compile_units with same filename +
                    dirname clash / duplicate labels
           Product: tools
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: llc
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: jvoung at google.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 8637
  --> http://llvm.org/bugs/attachment.cgi?id=8637
Test with two different compile units coming from same source file.

Reproducer:

(1) compile the SAME source file with different macros to get different bitcode
files, with debug info ("-g")
(2) link the two bitcode files (e.g., using llvm-link)
(3) compile with llc

You end up with two compile_units that have the same "ID" because only the
filename and dirname are used to generate an ID.  The "ID" is later used to
emit labels, so you end up with duplicate labels, and the following assertion
fires:


/home/x/llvm/lib/MC/MCAsmStreamer.cpp:337: virtual void <anonymous
namespace>::MCAsmStreamer::EmitLabel(llvm::MCSymbol *): Assertion
`Symbol->isUndefined() && "Cannot define a symbol twice!"' failed.
0  llc             0x0000000000c5b16f
1  llc             0x0000000000c5b689
2  libpthread.so.0 0x00007f59ea1918f0
3  libc.so.6       0x00007f59e9480a75 gsignal + 53
4  libc.so.6       0x00007f59e94845c0 abort + 384
5  libc.so.6       0x00007f59e9479941 __assert_fail + 241
6  llc             0x0000000000bf20ac
7  llc             0x0000000000892738 llvm::DwarfDebug::emitDebugInfo() + 232
8  llc             0x000000000089237e llvm::DwarfDebug::endModule() + 2798
9  llc             0x0000000000883c84
llvm::AsmPrinter::doFinalization(llvm::Module&) + 548
10 llc             0x0000000000bb01b1
llvm::FPPassManager::doFinalization(llvm::Module&) + 81
11 llc             0x0000000000bb0802
llvm::FPPassManager::runOnModule(llvm::Module&) + 82
12 llc             0x0000000000bb093a
llvm::MPPassManager::runOnModule(llvm::Module&) + 282
13 llc             0x0000000000bb0e71 llvm::PassManagerImpl::run(llvm::Module&)
+ 241
14 llc             0x0000000000bb0f9a llvm::PassManager::run(llvm::Module&) +
10
15 llc             0x00000000004e275c main + 4540
16 libc.so.6       0x00007f59e946bc4d __libc_start_main + 253
17 llc             0x00000000004e14d9


Some options to add additional information to the key for getting different
"ID"s in this case:

(1) Also go through the compile unit's enum types, retained types, subprograms,
global variables, and use that in the key.  However, this particular case is
pretty rare, so that seems like a waste.

(2) Use the address of the MDNode for key too...  I don't actually know if that
is viable.  It does look like there are really only two places where you
"constructCompileUnit", so maybe this is okay, but it is a bit gross.  See
attached patch for an example of this.



Test attached.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.