On Nov 13, 2012, at 10:51 AM, Eric Christopher <[email protected]> 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" _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
