[cfe-commits] r167799 - /cfe/trunk/lib/Driver/Tools.cpp

[Bill Wendling]

On Nov 13, 2012, at 10:51 AM, Eric Christopher <echristo at gmail.com> wrote:

> > dtrace uses the accelerator tables? How and why? The accelerator tables are built from the debug info that's going into the final file, I think you're conflating two problems here.
> >
> dtrace is munging through a bunch of code, some of it is the debug info. The accelerator tables are fubared going into the dtrace mode. Once I turned off the accel tables, the 'dwarfdump --verify' reported no errors. However, dtrace is still thrashing. I have to investigate via dtrace debugging and junk. But I still think this patch is worth keeping in for the time being, because it makes dwarfdump happy, which is certain to be an error during an Apple-style build...
> 
> What I'm saying is that I don't think you've identified the problem. If the accelerator tables are munged it's because the rest of the debug information is munged. Can you show a testcase, or problem, or anything here?
> 
I talked with Greg and he said that accel tables wouldn't work with LTO. The problem is triggered even with `-gline-tables-only'. I don't have a small testcase, but you need to build LLVM with LTO and `-gline-tables-only' then run dwarfdump on it like I said.

> Do you have a particular set of output from the verify to show what's going on here?
> 
These are the first several lines of the verify output. It's big.

-bw

----------------------------------------------------------------------
 File: /Volumes/Data/clang-bni-builds/clang-425.0.4.roots/clang-425.0.4~obj/dSYMs/llvm-lto.5TAqCX (x86_64)
----------------------------------------------------------------------
Verifying Compile Unit Header chain..... ok
Verifying .debug_info... ok
Verifying .apple_names...
ERROR: .apple_names bucket[0] hash[0] = 0x4afb481d str[0] = 0x0018aa3b die[0] = 0x00000602 is not a valid DIE offset for "FastEmit_ARMISD_VEXT_MVT_v4f32_rri"
ERROR: .apple_names bucket[0] hash[1] = 0x7d883d02 str[0] = 0x00008e3c die[0] = 0x000248ea is not a valid DIE offset for "__upper_bound<<anonymous>::LessOpcodeOperand &, const <anonymous>::OperandMatchEntry *, llvm::StringRef>"
ERROR: .apple_names bucket[2] hash[2] = 0x90a99fd9 str[0] = 0x001a1e31 die[0] = 0x00000000 is not a valid DIE offset for "__distance<std::__1::pair<llvm::DIE *, unsigned int> *>"
ERROR: .apple_names bucket[4] hash[3] = 0x9ec4d7b6 str[0] = 0x001a3d91 die[0] = 0x000005ce is not a valid DIE offset for "getLRCalc"
ERROR: .apple_names bucket[4] hash[3] = 0x9ec4d7b6 str[0] = 0x001a3d91 die[1] = 0x00000ac3 is not a valid DIE offset for "getLRCalc"
ERROR: .apple_names bucket[4] hash[3] = 0x9ec4d7b6 str[0] = 0x001a3d91 die[2] = 0x00000b9c is not a valid DIE offset for "getLRCalc"
ERROR: .apple_names bucket[5] hash[4] = 0xb22b76c2 str[0] = 0x00005064 die[0] = 0x000000a9 is not a valid DIE offset for "startswith"
ERROR: .apple_names bucket[5] hash[4] = 0xb22b76c2 str[0] = 0x00005064 die[1] = 0x000000af is not a valid DIE offset for "startswith"
ERROR: .apple_names bucket[5] hash[4] = 0xb22b76c2 str[0] = 0x00005064 die[2] = 0x0000010f is not a valid DIE offset for "startswith"
ERROR: .apple_names bucket[5] hash[4] = 0xb22b76c2 str[0] = 0x00005064 die[3] = 0x00000146 is not a valid DIE offset for "startswith"
ERROR: .apple_names bucket[5] hash[4] = 0xb22b76c2 str[0] = 0x00005064 die[4] = 0x00000175 is not a valid DIE offset for "startswith"