Line endings in lldb repository

Hi all,
could someone (TM) please go over all files in the repository and ensure
that they use consistent (UNIX) line endings like all other LLVM
subprojects do? Especially the CMakeLists.txt are using DOS-style line
endings.

Joerg

DOS style line endings are in the following files:

CMakeLists.txt
scripts/Python/python-wrapper.swig
source/API/CMakeLists.txt
source/Breakpoint/CMakeLists.txt
source/CMakeLists.txt
source/Commands/CMakeLists.txt
source/Core/CMakeLists.txt
source/DataFormatters/CMakeLists.txt
source/Expression/CMakeLists.txt
source/Host/CMakeLists.txt
source/Host/common/CMakeLists.txt
source/Host/linux/CMakeLists.txt
source/Interpreter/CMakeLists.txt
source/Plugins/ABI/CMakeLists.txt
source/Plugins/ABI/MacOSX-arm/CMakeLists.txt
source/Plugins/ABI/MacOSX-i386/CMakeLists.txt
source/Plugins/ABI/SysV-x86_64/CMakeLists.txt
source/Plugins/CMakeLists.txt
source/Plugins/Disassembler/CMakeLists.txt
source/Plugins/Disassembler/llvm/CMakeLists.txt
source/Plugins/DynamicLoader/CMakeLists.txt
source/Plugins/DynamicLoader/Darwin-Kernel/CMakeLists.txt
source/Plugins/DynamicLoader/MacOSX-DYLD/CMakeLists.txt
source/Plugins/DynamicLoader/POSIX-DYLD/CMakeLists.txt
source/Plugins/DynamicLoader/Static/CMakeLists.txt
source/Plugins/Instruction/ARM/CMakeLists.txt
source/Plugins/Instruction/CMakeLists.txt
source/Plugins/LanguageRuntime/CMakeLists.txt
source/Plugins/LanguageRuntime/CPlusPlus/CMakeLists.txt
source/Plugins/LanguageRuntime/CPlusPlus/ItaniumABI/CMakeLists.txt
source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/CMakeLists.txt
source/Plugins/LanguageRuntime/ObjC/CMakeLists.txt
source/Plugins/ObjectContainer/BSD-Archive/CMakeLists.txt
source/Plugins/ObjectContainer/CMakeLists.txt
source/Plugins/ObjectContainer/Universal-Mach-O/CMakeLists.txt
source/Plugins/ObjectFile/CMakeLists.txt
source/Plugins/ObjectFile/ELF/CMakeLists.txt
source/Plugins/ObjectFile/Mach-O/CMakeLists.txt
source/Plugins/ObjectFile/PECOFF/CMakeLists.txt
source/Plugins/OperatingSystem/CMakeLists.txt
source/Plugins/Platform/CMakeLists.txt
source/Plugins/Platform/gdb-server/CMakeLists.txt
source/Plugins/Platform/MacOSX/CMakeLists.txt
source/Plugins/Platform/POSIX/CMakeLists.txt
source/Plugins/Process/CMakeLists.txt
source/Plugins/SymbolFile/CMakeLists.txt
source/Plugins/SymbolFile/DWARF/CMakeLists.txt
source/Plugins/SymbolFile/Symtab/CMakeLists.txt
source/Plugins/SymbolVendor/CMakeLists.txt
source/Plugins/SymbolVendor/ELF/CMakeLists.txt
source/Plugins/SymbolVendor/MacOSX/CMakeLists.txt
source/Plugins/UnwindAssembly/CMakeLists.txt
source/Plugins/UnwindAssembly/InstEmulation/CMakeLists.txt
source/Plugins/UnwindAssembly/x86/CMakeLists.txt
source/Symbol/CMakeLists.txt
source/Target/CMakeLists.txt
source/Utility/CMakeLists.txt
tools/CMakeLists.txt
tools/driver/CMakeLists.txt
tools/lldb-platform/CMakeLists.txt
www/architecture.html
www/build.html
www/customization.html
www/docs.html
www/download.html
www/faq.html
www/features.html
www/formats.html
www/goals.html
www/index.html
www/python-reference.html
www/scripting.html
www/source.html
www/style.css
www/symbolication.html
www/symbols.html
www/troubleshooting.html
www/tutorial.html

Any objection to apply the result of tr -d '\r' to those?

Joerg

No objections here. Any objections from any of the folks developing on
Windows?

Dan

Doesn't SVN automatically convert line endings when you do a checkout?

Richard Mitton
richard@codersnotes.com

I have an Ubuntu 12.10 machine where inferior_asserting() succeeds when functionalities/inferior-asserting is run in isolation with either of clang or gcc, but fails when dotest.py is used to run the full suite. When it fails, the backtrace is missing all function arguments. A diff of the attached logs illustrates that RegisterContextLLDB comes up with a more complete register set in the passing case.

Note: th1/fr1 frame uses eh_frame CFI for full UnwindPlan

Any guesses from the logs where I'd be looking to root cause this funkiness??

- Ashok

  th1/fr2 looking for register saved location for reg 16
th1/fr1 supplying caller's saved reg 16's location, cached
  th1/fr2 looking for register saved location for reg 1
th1/fr1 could not supply caller's reg 1 location
th1/fr0 supplying caller's register 1 from the live RegisterContext at frame 0
th1/fr1 looking for register saved location for reg 1
th1/fr0 supplying caller's saved reg 1's location, cached
th1/fr0 looking for register saved location for reg 1
th1/fr0 passing along to the live register context for reg 1
  th1/fr2 looking for register saved location for reg 16
th1/fr1 supplying caller's saved reg 16's location, cached
  th1/fr2 looking for register saved location for reg 12
th1/fr1 could not supply caller's reg 12 location
th1/fr0 supplying caller's register 12 from the live RegisterContext at frame 0
th1/fr1 looking for register saved location for reg 12
th1/fr0 supplying caller's saved reg 12's location, cached
th1/fr0 looking for register saved location for reg 12
th1/fr0 passing along to the live register context for reg 12
  th1/fr2 looking for register saved location for reg 16
th1/fr1 supplying caller's saved reg 16's location, cached
  th1/fr2 looking for register saved location for reg 6
th1/fr1 could not supply caller's reg 6 location
th1/fr0 supplying caller's saved reg 6's location, cached
th1/fr1 looking for register saved location for reg 6
th1/fr0 supplying caller's saved reg 6's location, cached
th1/fr0 looking for register saved location for reg 6
th1/fr0 passing along to the live register context for reg 6
  th1/fr2 looking for register saved location for reg 16
th1/fr1 supplying caller's saved reg 16's location, cached
  th1/fr2 looking for register saved location for reg 2
th1/fr1 did not supply reg location for 2 (rcx) because it is volatile
  th1/fr2 looking for register saved location for reg 16
th1/fr1 supplying caller's saved reg 16's location, cached
  th1/fr2 looking for register saved location for reg 8
th1/fr1 did not supply reg location for 8 (r8) because it is volatile

bt-fail.log (36.1 KB)

bt-ok.log (10.4 KB)

Only if the files are tagged such.

Joerg

Ashok, for what it's worth I can't see what would cause this difference between the two runs based on the log files.

Is it possible that lldb is stopped at different places when the thread backtrace all is invoked? The lldb unwind log isn't printing the pc values of thread 1 frame 0. thread 1 is clearly the same in both - we have the exact same pc value and we're using the same unwind instructions from the eh_frame.

This is a little odd -

  th1/fr2 looking for register saved location for reg 2
th1/fr1 did not supply reg location for 2 (rcx) because it is volatile
  th1/fr2 looking for register saved location for reg 16
th1/fr1 supplying caller's saved reg 16's location, cached
  th1/fr2 looking for register saved location for reg 8
th1/fr1 did not supply reg location for 8 (r8) because it is volatile

Why would lldb be trying to examine something in rcx or r8 in frame 2 here? There must be a variable whose location list says it is live at the call site in that register - poor DWARF from the compiler.

The fact that we don't see the same thing in the bt-fail.log case makes me wonder if the debug info isn't different -- or absent?

I think you might be looking at the same bug that I am.

The problem is that TestSettings.py changes the frame format string, and doesn't restore it to the correct value.
But I think the real problem is that dotest.py executes multiple tests using the same context (I just posted a mail about this).

Richard Mitton
richard@codersnotes.com

Yeah, those sound like more likely to be the core problem than the unwinder in this case.. I haven't had a chance to look into the failure yet myself though. :confused:

Bingo, thanks! TestInferiorAssert.py passes for me with the attached patch. Even better, it would be nice to cache the initial result of runCmd("settings show frame-format") so that this doesn't drift with changes to default settings...

- Ashok

TestSettings.patch (830 Bytes)

Perhaps we should add a "settings reset" command that clears all settings values back to their defaults, and run that as part of the "lldbtest.setUp"? I don't think there is much beyond settings that can persist from target to target. That would be useful thing to add in any case.

Jim

For now, I fixed this in r191378 using self.res.GetOutput() after self.runCmd(). Thanks again for root-causing this one,

- Ashok