Dec 7 2015
Nov 23 2015
Handled by another patch
Sep 11 2015
Aug 26 2015
I tried deleting the target and setting the platform to the host platform at the end of the test in TestDisassemble_VST1_64.py, but that didn't solve the problem.
The problem with this test is it gets python in a bad state, so after it's run, all tests after error out. It runs fine on its own, but something like:
The error also happens on Linux; this test should be turned off everywhere.
Aug 25 2015
My guess is the target create is failing. This line in the test:
Aug 24 2015
This is essentially reverting http://reviews.llvm.org/rL237053 , so we'd go back to the problem with it - LLDB won't be able to set the platform based on the architecture in the target binary, but will use the currently selected platform, even if it's not compatible.
Jul 13 2015
I agree that the current implementation is annoying with using the platform selected at target creation time, but changing the platform for a target after it is created might be dangerous because it can cache information from the platform.
Jun 4 2015
May 14 2015
This codepath also fixes mangling issues with Hexagon binaries. Please add
|| (arch.GetTriple().GetMachine() == llvm::Triple::hexagon)
to the if, to pick up the fix for Hexagon.
May 13 2015
This affects Windows and Hexagon as well, FYI. I believe this will fix bug 22177.
I wonder if it's reporting not compatible because the platform isn't connected yet, and currently the non-host linux platform needs to be connected.
Adding table after check for remote platform, as requested.
This change will look for a compatible platform if the current platform is not compatible with the current architecture.
May 12 2015
The problem with querying PlatformGDBRemote is it's only valid if you're connected to the remote platform. I'm trying to set the Platform when creating a target, so there is no connection yet.
What I'm trying to do is allow a user to load an arbitrary Linux binary and have LLDB select the Remote Linux Platform, if the architecture is one of our supported Linuxes. My goal is to be able to remotely debug Hexagon Linux binaries on Windows.
May 11 2015
That's a good point - breakpoints set on functions or source lines will get the start of a packet, but if the user sets a breakpoint on an address we should fix that to set it at the start of the packet containing that address.
May 8 2015
May 7 2015
InstructionList::GetIndexOfNextBranchInstruction() is only called from one spot, ThreadPlanStepRange::SetNextBranchBreakpoint(), and it needs a Target to get the the ArchSpec to check for Hexagon. I could change it to only do the check if the Target wasn't nullptr, but that seems unnecessary to me.
Changed parameter from ProcessSP to Target, as requested.
May 6 2015
Code moved to GetIndexOfNextBranchInstruction(), as requested.
May 4 2015
The problem with a Hexagon-specific testcase is it would need to use the Hexagon simulator, which is not currently publicly available. We expect it to be available later this year.
May 1 2015
Apr 30 2015
Apr 29 2015
Whoops - missed the do loop upping the size of the buffer to the return value. But I can't find any documentation saying that GetCurrentDirectory() supports paths > MAX_PATH. Are we sure it does?
llvm::sys::fs::current_path() doesn't handle paths > MAX_PATH-1:
Apr 27 2015
Replace erroneously removed comment
Changed getcwd() and chdir() to use _getcwd() and _chdir().
Apr 17 2015
Apr 14 2015
Friendly ping. This behaves as expected - selecting a compatible platform will use it; selecting an incompatible platform and lldb will find a compatible one.
Apr 13 2015
The spaces bother me too. Ewan, please remove them.
Apr 10 2015
The comment isn't there to get line and file; it's there to get symbolic branch targets.
So if I specify -DPYTHON_HOME:STRING=c:\pythonfoo, it will pick up the python includes and library from c:\pythonfoo, and if LLDB_RELOCATABLE_PYTHON is set to 0, lldb will use c:\pythonfoo as PYTHONHOME?
Apr 6 2015
This will do that - platform_sp is the currently selected platform, and both calls to SetSelectedPlatform() are gated by !platform_sp->IsCompatibleArchitecture(), so it will only search for a new platform if the architecture is not compatible with the currently selected platform.
Apr 3 2015
Jim, if I select a platform, then load a target that the platform is not compatible with, should it use the incompatible platform, or find one that is compatible?
Mar 31 2015
It should use the current Platform, but only if it is compatible with the target's architecture, right? I believe it does this already, because any change of platform_sp is gated by if(!platform_sp->IsCompatibleArchitecture()).
Mar 30 2015
Mar 26 2015
I'm seeing less failures, but I'm still seeing some with this patch:
Mar 20 2015
I would like ctrl-c to not exit lldb-mi. "quit" exits, and it's too easy to hit ctrl-c when the target isn't running and accidentally exit lldb-mi.
gdb handles command line gdb and MI in one executable. I think lldb should do the same. We ship one executable, called hexagon-lldb, that is actually lldb-mi. Pass --interpreter and it runs MI, otherwise it runs the standard LLDB CLI.