Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[SR-10511] swift-lldb doesn't recognize arm64e #4572

Closed
swift-ci opened this issue Apr 18, 2019 · 6 comments
Closed

[SR-10511] swift-lldb doesn't recognize arm64e #4572

swift-ci opened this issue Apr 18, 2019 · 6 comments
Labels
bug Something isn't working LLDB for Swift

Comments

@swift-ci
Copy link

Previous ID SR-10511
Radar None
Original Reporter ivhernandez (JIRA User)
Type Bug
Status Resolved
Resolution Won't Do
Environment

Mac Pro (Late 2013)

Mac OS X 10.14.3

lldb version 7.0.0 (buildbot 2019-03-25)
Swift-5.0 (revision ba33f9e0b772015326bdecc0d597b2ac9fc61717)
clang revision 5c9d04dc0697297a47b5edb0c1a581b306a42bdb
llvm revision 3207a50965a98cdc2f42a934f158c38182be7257

Additional Detail from JIRA
Votes 0
Component/s LLDB for Swift
Labels Bug
Assignee None
Priority Medium

md5: 3e6ce937fe2b85dd5f4ebcf7b6550996

Issue Description:

Issue
swift-lldb is crashing when attempting to debug an iOS application on an iPhone XS Max. I set the triple to 'arm64-apple-ios' because 'arm64e-apple-ios' results in the error message "error: invalid triple 'arm64e-apple-ios'". Creating the target and launching the application works fine but a crash occurs when resolving a breakpoint. The archspec is set to 'unknown-apple-ios--' at some point and replaces 'arm64-apple-ios' in the Target::MergeArchitecture(ArchSpec) function. This later ends up causing a crash in Platform::GetSoftwareBreakpointTrapOpcode(Target, BreakpointSite) due to "unhandled architecture".

I'm using the lldb included in the swift 5.0 release toolchain.

I've been working around this by ignoring the new architecture and returning the arm64 arch in Target::MergeArchitecture(ArchSpec).

My Python script:
import lldb

LOCAL_PATH="/local/path/to/app/App.app/App"
REMOTE_PATH="/remote/path/to/app/App.app/App"
TRIPLE="arm64-apple-ios"
PLATFORM="remote-ios"
ADDR="connect://localhost:67109"

def set_error(result, error):
if error.Success():
return False
result.SetError(error)
return True

class LaunchRemoteIos:
def init(self, debugger, session_dict):
print("Inited.")

def call(self, debugger, command, exe_ctx, result):
debugger = debugger if debugger else lldb.SBDebugger.Create()
result = lldb.SBCommandReturnObject()
error = lldb.SBError()

# `target create` && `platform select`
target = debugger.CreateTarget(LOCAL_PATH, TRIPLE, PLATFORM, True, error)
if set_error(result, error): return

# Remote target create
target.modules[0].SetPlatformFileSpec(lldb.SBFileSpec(REMOTE_PATH))

# `platform connect`
process = target.ConnectRemote(debugger.GetListener(), ADDR, None, error)
if set_error(result, error): return

# `launch`
launch_info = lldb.SBLaunchInfo([])
target.Launch(launch_info, error)
if set_error(result, error): return

def __lldb_init_module(debugger, internal_dict):
debugger.HandleCommand('command script add -c script.LaunchRemoteIos launch-ios')

The stack trace:
ivanhernandez@macpro:/Users/ivanhernandez/Desktop$ /Library/Developer/Toolchains/swift-5.0-RELEASE.xctoolchain/usr/bin/lldb
(lldb) command script import script.py
Inited.
(lldb) launch-ios
Unhandled architecture in Platform::GetSoftwareBreakpointTrapOpcode
UNREACHABLE executed at /Users/buildnode/jenkins/workspace/oss-swift-5.0-package-osx/lldb/source/Target/Platform.cpp:1931!
0 lldb 0x0000000101c8fae5 llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 37
1 lldb 0x0000000101c8ed57 llvm::sys::RunSignalHandlers() + 39
2 lldb 0x0000000101c90142 SignalHandler(int) + 258
3 libsystem_platform.dylib 0x00007fff79e56b3d _sigtramp + 29
4 libsystem_platform.dylib 0x000000010791e0a8 _sigtramp + 2376889736
5 libsystem_c.dylib 0x00007fff79d141c9 abort + 127
6 LLDB 0x0000000108081562 llvm::llvm_unreachable_internal(char const*, char const*, unsigned int) + 530
7 LLDB 0x000000010b622f3a lldb_private::Platform::GetSoftwareBreakpointTrapOpcode(lldb_private::Target&, lldb_private::BreakpointSite*) + 470
8 LLDB 0x000000010b62bbf5 lldb_private::Process::GetSoftwareBreakpointTrapOpcode(lldb_private::BreakpointSite*) + 77
9 LLDB 0x000000010b545907 lldb_private::process_gdb_remote::ProcessGDBRemote::EnableBreakpointSite(lldb_private::BreakpointSite*) + 201
10 LLDB 0x000000010b62b63c lldb_private::Process::CreateBreakpointSite(std::__1::shared_ptr<lldb_private::BreakpointLocation> const&, bool) + 510
11 LLDB 0x000000010b307990 lldb_private::BreakpointLocation::ResolveBreakpointSite() + 94
12 LLDB 0x000000010b30dd6b lldb_private::BreakpointLocationList::AddLocation(lldb_private::Address const&, bool, bool*) + 195
13 LLDB 0x000000010b2f84f6 lldb_private::Breakpoint::AddLocation(lldb_private::Address const&, bool*) + 34
14 LLDB 0x000000010b312551 lldb_private::BreakpointResolver::AddLocation(lldb_private::Address, bool*) + 39
15 LLDB 0x000000010b315e87 lldb_private::BreakpointResolverAddress::SearchCallback(lldb_private::SearchFilter&, lldb_private::SymbolContext&, lldb_private::Address*, bool) + 557
16 LLDB 0x000000010b3fc259 lldb_private::SearchFilter::Search(lldb_private::Searcher&) + 93
17 LLDB 0x000000010b657099 lldb_private::Target::AddBreakpoint(std::__1::shared_ptr<lldb_private::Breakpoint>, bool) + 211
18 LLDB 0x000000010b65846c lldb_private::Target::CreateBreakpoint(std::**1::shared_ptr<lldb_private::SearchFilter>&, std::_1::shared_ptr<lldb_private::BreakpointResolver>&, bool, bool, bool) + 272
19 LLDB 0x000000010b6595eb lldb_private::Target::CreateBreakpoint(lldb_private::Address const&, bool, bool) + 291
20 LLDB 0x000000010b658c8b lldb_private::Target::CreateBreakpoint(unsigned long long, bool, bool) + 121
21 LLDB 0x000000010b61b7eb DynamicLoaderMacOS::SetNotificationBreakpoint() + 195
22 LLDB 0x000000010b62defe lldb_private::Process::Launch(lldb_private::ProcessLaunchInfo&) + 936
23 LLDB 0x000000010b664633 lldb_private::Target::Launch(lldb_private::ProcessLaunchInfo&, lldb_private::Stream*) + 1091
24 LLDB 0x000000010798a18c lldb::SBTarget::Launch(lldb::SBLaunchInfo&, lldb::SBError&) + 626
25 LLDB 0x0000000107a4e3cb _wrap_SBTarget_Launch(_object*, _object*) + 535
26 Python 0x00007fff56e0e11f PyEval_EvalFrameEx + 14717
27 Python 0x00007fff56e0a588 PyEval_EvalCodeEx + 1540
28 Python 0x00007fff56e1079c _PyEval_SliceIndex + 498
29 Python 0x00007fff56e0e45a PyEval_EvalFrameEx + 15544
30 Python 0x00007fff56e0a588 PyEval_EvalCodeEx + 1540
31 Python 0x00007fff56db1d88 PyFunction_SetClosure + 797
32 Python 0x00007fff56d949a7 PyObject_Call + 97
33 Python 0x00007fff56d9f053 PyMethod_New + 1176
34 Python 0x00007fff56d949a7 PyObject_Call + 97
35 Python 0x00007fff56e10158 PyEval_CallObjectWithKeywords + 159
36 LLDB 0x000000010b7af736 lldb_private::PythonCallable::operator()(std::initializer_list<lldb_private::PythonObject>) + 50
37 LLDB 0x00000001079e092b lldb_private::PythonObject lldb_private::PythonCallable::operator()<lldb_private::PythonObject, lldb_private::PythonString, lldb_private::PythonObject, lldb_private::PythonObject>(lldb_private::PythonObject const&, lldb_private::PythonString, lldb_private::PythonObject, lldb_private::PythonObject) + 191
38 LLDB 0x00000001079e06bd LLDBSwigPythonCallCommandObject + 484
39 LLDB 0x000000010b6f623e lldb_private::ScriptInterpreterPython::RunScriptBasedCommand(std::
_1::shared_ptr<lldb_private::StructuredData::Generic>, llvm::StringRef, lldb_private::ScriptedCommandSynchronicity, lldb_private::CommandReturnObject&, lldb_private::Status&, lldb_private::ExecutionContext const&) + 472
40 LLDB 0x000000010b338cac CommandObjectScriptingObject::DoExecute(llvm::StringRef, lldb_private::CommandReturnObject&) + 160
41 LLDB 0x000000010b4d6b0e lldb_private::CommandObjectRaw::Execute(char const*, lldb_private::CommandReturnObject&) + 310
42 LLDB 0x000000010b4ca471 lldb_private::CommandInterpreter::HandleCommand(char const*, lldb_private::LazyBool, lldb_private::CommandReturnObject&, lldb_private::ExecutionContext*, bool, bool) + 1967
43 LLDB 0x000000010b4cd3f0 lldb_private::CommandInterpreter::IOHandlerInputComplete(lldb_private::IOHandler&, std::_1::basic_string<char, std::1::char_traits<char>, std::_1::allocator<char> >&) + 372
44 LLDB 0x000000010b4eca41 lldb_private::IOHandlerEditline::Run() + 255
45 LLDB 0x000000010b3a9b70 lldb_private::Debugger::ExecuteIOHandlers() + 68
46 LLDB 0x000000010b4ce07a lldb_private::CommandInterpreter::RunCommandInterpreter(bool, bool, lldb_private::CommandInterpreterRunOptions&) + 156
47 LLDB 0x00000001079adf12 lldb::SBDebugger::RunCommandInterpreter(bool, bool) + 68
48 lldb 0x0000000101c28514 Driver::MainLoop() + 2442
49 lldb 0x0000000101c28a9d main + 306
50 libdyld.dylib 0x00007fff79c6bed9 start + 1
51 libdyld.dylib 0x0000000000000001 start + 2251899177
Stack dump:
0. Program arguments: /Library/Developer/Toolchains/swift-5.0-RELEASE.xctoolchain/usr/bin/lldb
Abort trap: 6

@belkadan
Copy link

It's true that the Swift Open Source Project releases do not have support for arm64e, but it shouldn't crash.

cc @dcci

@dcci
Copy link
Mannequin

dcci mannequin commented Apr 22, 2019

Yes, you're right, this shouldn't crash. Let me try reproducing it.

@dcci
Copy link
Mannequin

dcci mannequin commented Apr 22, 2019

Yes, the issue is that if we can't get a software breakpoint trap opcode, we crash.

default:
    llvm_unreachable(
        "Unhandled architecture in Platform::GetSoftwareBreakpointTrapOpcode");
  }

@dcci
Copy link
Mannequin

dcci mannequin commented Apr 22, 2019

This is a change I want to push upstream.

@dcci
Copy link
Mannequin

dcci mannequin commented Apr 22, 2019

I spoke with @jasonmolenda about this as he implemented the support and he does believe that lldb won't go far even if we remove this assertion. I would claim that having this assertion in place is actually really useful because it helps porting to new architectures so I'm really not inclined to remove it. You might want to use an Apple released toolchain which has the support.

@jasonmolenda
Copy link

yeah, the debugger will crash in a half dozen different places when targeting an architecture it doesn't have support for yet. It would be possible to have lldb recognize the cpu type and cpu subtype of an arm64e process and error out immediately at the start of the debug session, but hopefully the arm64e patches can be integrated in the not too distant future and this won't be a problem.

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
@shahmishal shahmishal transferred this issue from apple/swift May 7, 2022
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working LLDB for Swift
Projects
None yet
Development

No branches or pull requests

3 participants