[SR-517] lldb: Provide an easy way to print object at address in Swift mode, like 'po <integer>' in ObjC

[jckarter]

Previous ID	SR-517
Radar	rdar://problem/48448415
Original Reporter	@jckarter
Type	New Feature
Status	Reopened
Resolution

Additional Detail from JIRA

Votes	4
Component/s	LLDB for Swift
Labels	New Feature
Assignee	granataenrico (JIRA)
Priority	Medium

md5: f3787f2f15d7e034c517dcfa2132f811

Issue Description:

https://twitter.com/an0/status/681152454361128962

Having 'po' print an integer literal as an integer is nice and orthogonal, but also totally useless. It would be nice to preserve the ObjC behavior of treating the integer like an object reference and attempting to debugPrint the object.

[swift-ci]

Comment by Enrico Granata (JIRA)

That would actually be wrong. It is already quite of a hack in Objective-C, where it can lead to random results (e.g. care to guess what 0x1 or 0x5 mean when you pretend it's a pointer?), but at the very least you can somewhat defend it there on the grounds that every object in ObjC is going to have a pointer value

In Swift, not everything that is a Swift object worth talking about has such an obvious pointer value (structs, tuples, enums, anyone?), so pretending that any number could be a pointer is actually not a reasonable behavior, and - again - doing this is already an implementation hack anyway

If you have a number that you know represents a class instance, po unsafeBitCast(0x123, MyClass.self) is what you want to do. And if you don't know that it represents an object of some class - or any class even - we are in no position to make a general educated guess, because again not everything is a class with an attached isa in Swift.

So, sorry, but it po <hex-literal> should NOT replicate the hackery of its ObjC counterpart.

[swift-ci]

Comment by Kate Stone (JIRA)

While it's not entirely obvious that we should be special-casing "po" along these lines, I agree that it's unfortunate that we don't have a simple way to examine references from a raw address.

One possibility is indeed that any Int result that is also an apparently valid pointer for a reference type gets evaluated in this manner, perhaps as one of several representations shown. Running Swift code with something that merely looks valid can be dangerous in its own right and lead to surprising results.

Enrico? Any immediate thoughts about how we'd want to accommodate this scenario?

[swift-ci]

Comment by Kate Stone (JIRA)

Think about this in the spirit of the request rather than the literal ask.

[jckarter]

Thanks Kate. I updated the title to be less prescriptive of the solution.

[swift-ci]

Comment by Enrico Granata (JIRA)

We have had some discussion about how we might hack this (because I still maintain it is a hack)

One possible way would be for us to have the "po" command be a regular expression command (or, similarly, for the expression parser to recognize if the print-object-description mode is on) such that if the input is merely a number literal (and just a number literal, no pointer arithmetic), then this would turn your expression evaluation into simply generating a const value of the right type (AnyObject, in this case) and the pointer value you passed, and then 'po' that

Obviously, doing that would mean that you end up with things like po 1, po 5, po (IIRC) 137, meaning entirely wrong (and counterintuitive) things - because tagged pointers

[swift-ci]

Comment by Kate Stone (JIRA)

Again, ignore the literal request to use "po 0x<address>" as the syntax. If a user has an address and wants to examine the Swift instance the address points to, what is our solution? Arguably this is something a more raw command like 'frame var 0x<address>' could excel at, though it distorts the meaning of the command beyond recognition and it conflates the notion of how you want to examine it with what you want to examine.

Should po take a parameter that indicates that you aren't providing an expression at all, but rather an address that we want a debug description of? Introducing a fourth command to the frame var / p / po cycle seems less than desirable. Let's talk about this and see where it leads.

[kastiglione]

This issue comes up regularly, and it's three years later. Maybe this discussion can be revisited?

@jckarter it appears you're the only one on this thread still active on bugs.swift.org, would it be good to bring in current lldb folks to weigh in?

[jckarter]

I pinged friss (JIRA User) about this. Maybe we could provide a Swift library to be automatically loaded into lldb sessions that adds some conveniences to make it easier to turn address literals back into object pointers and/or Swift values.