lldb: print formatters format inconsistently

[davidtwco]

One of rustc's debuginfo tests is failing with newer versions of lldb. I'm testing locally with a build of d43f324.

When printing an instance of std::num::NonZeroI8 (which has a trivial pretty printer in our test suite, included below):

(lldb) print/d nz_i8
(core::num::nonzero::NonZeroI8) $0 = '\v' { __0 = 11 }

The /d suffix seems to only apply to the printing of 11 but not the '\v. I can confirm this by requesting a different formatting and see it only change the 11.

As far as I can tell, it used to apply to both in previous versions (as our test expects $0 = 11 and passes with earlier versions of lldb). Using print or frame variable or any other command I've found doesn't seem to make a difference.

You should be able to reproduce it using the following:

// numeric-types.rs
use std::num::*;

fn main() {
    let nz_i8 = NonZeroI8::new(11).unwrap();
    zzz(); // #break
}

fn zzz() { }

(original)

# lldb_lookup.py
import re

class RustType(object):
    OTHER = "Other"
    STRUCT = "Struct"
    STD_NONZERO_NUMBER = "StdNonZeroNumber"

STD_NONZERO_NUMBER_REGEX = re.compile(r"^core::num::([a-z_]+::)*NonZero.+$")

STD_TYPE_TO_REGEX = {
    RustType.STD_NONZERO_NUMBER: STD_NONZERO_NUMBER_REGEX,
}

def classify_rust_type(type):
    type_class = type.GetTypeClass()
    if type_class == lldb.eTypeClassStruct:
        return classify_struct(type.name, type.fields)
    return RustType.OTHER

def classify_struct(name, fields):
    for ty, regex in STD_TYPE_TO_REGEX.items():
        if regex.match(name):
            return ty

    return RustType.STRUCT

def summary_lookup(valobj, dict):
    # type: (SBValue, dict) -> str
    """Returns the summary provider for the given value"""
    rust_type = classify_rust_type(valobj.GetType())

    if rust_type == RustType.STD_NONZERO_NUMBER:
        return StdNonZeroNumberSummaryProvider(valobj, dict)

    return ""

def StdNonZeroNumberSummaryProvider(valobj, _dict):
    # type: (SBValue, dict) -> str
    objtype = valobj.GetType()
    field = objtype.GetFieldAtIndex(0)
    element = valobj.GetChildMemberWithName(field.name)
    return element.GetValue()

(original providers and original lookup and original types)

$ rustc -g numeric-types.rs

(lldb) type summary add -F -F lldb_lookup.summary_lookup  -e -x -h '^core::num::([a-z_]+::)*NonZero.+$' --category Rust
(lldb) type category enable Rust
(lldb) breakpoint set --file 'numeric-types.rs' --line 5
(lldb) print/d nz_i8

(original)

You can also just clone the rust-lang/rust repository and run ./x.py test tests/debuginfo --test-args numeric-types.

[llvmbot]

@llvm/issue-subscribers-lldb

[DavidSpickett]

As far as I can tell, it used to apply to both in previous versions (as our test expects $0 = 11 and passes with earlier versions of lldb).

I assume this was released versions, do you happen to know which ones?

[davidtwco]

As far as I can tell, it used to apply to both in previous versions (as our test expects $0 = 11 and passes with earlier versions of lldb).

I assume this was released versions, do you happen to know which ones?

I noticed it on macOS (Xcode 15.0 Beta 7):

lldb-1500.0.22.5
Apple Swift version 5.9 (swiftlang-5.9.0.128.106 clang-1500.0.40.1)

I built locally to confirm it wasn't a change from Apple's fork, and it doesn't appear to be. Our CI is still on an older version of lldb, so it hasn't affected us yet in that capacity, I'm just getting ahead of the change to make sure everything continues to pass as more users start using newer versions. I presume there is a release version but I don't have time to check at the moment, will update this when I can.

[DavidSpickett]

Thanks, I'll try a few versions of upstream and bisect it.

[DavidSpickett]

Reproduced it from main e6260ec49c5d16dc93ebe8b53e645200a0cfc0cd. There are some line breaks but the content is the same.

Had to add import lldb to the formatter and break on line 6 just after the variable was declared.

$ ./bin/lldb /tmp/test.o -o "script import lldb_lookup" -o "type summary add -F lldb_lookup.summary_lookup  -e -x -h '^core::num::([a-z_]+::)*NonZero.+$' --category Rust" -o "type category enable Rust" -o "b test.rs:6" -o "run" -o "print/d nz_i8"
(lldb) target create "/tmp/test.o"
Current executable set to '/tmp/test.o' (aarch64).
(lldb) script import lldb_lookup
(lldb) type summary add -F lldb_lookup.summary_lookup  -e -x -h '^core::num::([a-z_]+::)*NonZero.+$' --category Rust
(lldb) type category enable Rust
(lldb) b test.rs:6
Breakpoint 1: where = test.o`test::main::hb4d3c5bcd986131c + 32 at test.rs:6:5, address = 0x0000000000006de4
(lldb) run
Process 3545387 stopped
* thread #1, name = 'test.o', stop reason = breakpoint 1.1
    frame #0: 0x0000aaaaaaab0de4 test.o`test::main::hb4d3c5bcd986131c at test.rs:6:5
   3
   4    fn main() {
   5        let nz_i8 = NonZeroI8::new(11).unwrap();
-> 6        zzz(); // #break
   7    }
   8
   9    fn zzz() { }
Process 3545387 launched: '/tmp/test.o' (aarch64)
(lldb) print/d nz_i8
(core::num::nonzero::NonZeroI8) '\v' {
  __0 = 11
}

lldb 15 branch:

(lldb) print/d nz_i8
(core::num::nonzero::NonZeroI8) $0 = 11 {
  __0 = 11
}

So something has changed for sure.

[jimingham]

I don't have a setup to test this, but it might be interesting to try this with `expr` rather than `print`. print has changed from being `expr --` to the `dwim-print` by default. This is a simple local access, so it probably didn't actually go through the expression parser and maybe in that case dwim-print is dropping the format when making the result value object? Jim

…

On Aug 29, 2023, at 10:07 AM, David Spickett ***@***.***> wrote: Reproduced it from main e6260ec. There are some line breaks but the content is the same. Had to add import lldb to the formatter and break on line 6 just after the variable was declared. $ ./bin/lldb /tmp/test.o -o "script import lldb_lookup" -o "type summary add -F lldb_lookup.summary_lookup -e -x -h '^core::num::([a-z_]+::)*NonZero.+$' --category Rust" -o "type category enable Rust" -o "b test.rs:6" -o "run" -o "print/d nz_i8" (lldb) target create "/tmp/test.o" Current executable set to '/tmp/test.o' (aarch64). (lldb) script import lldb_lookup (lldb) type summary add -F lldb_lookup.summary_lookup -e -x -h '^core::num::([a-z_]+::)*NonZero.+$' --category Rust (lldb) type category enable Rust (lldb) b test.rs:6 Breakpoint 1: where = test.o`test::main::hb4d3c5bcd986131c + 32 at test.rs:6:5, address = 0x0000000000006de4 (lldb) run Process 3545387 stopped * thread #1, name = 'test.o', stop reason = breakpoint 1.1 frame #0: 0x0000aaaaaaab0de4 test.o`test::main::hb4d3c5bcd986131c at test.rs:6:5 3 4 fn main() { 5 let nz_i8 = NonZeroI8::new(11).unwrap(); -> 6 zzz(); // #break 7 } 8 9 fn zzz() { } Process 3545387 launched: '/tmp/test.o' (aarch64) (lldb) print/d nz_i8 (core::num::nonzero::NonZeroI8) '\v' { __0 = 11 } lldb 15 branch: (lldb) print/d nz_i8 (core::num::nonzero::NonZeroI8) $0 = 11 { __0 = 11 } So something has changed for sure. — Reply to this email directly, view it on GitHub <#65076 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADUPVW6ISXMCKW4GRGSDJW3XXYOVNANCNFSM6AAAAAA4DFYPZI>. You are receiving this because you are on a team that was mentioned.

[DavidSpickett]

Spot on.

$ git bisect good
9584ef1b02c0c2f77454c15008cb4a047a91a348 is the first bad commit
commit 9584ef1b02c0c2f77454c15008cb4a047a91a348
Author: Dave Lee <davelee.com@gmail.com>
Date:   Fri Feb 17 19:53:16 2023 -0800

    Recommit "[lldb] Redefine p alias to dwim-print command"

9584ef1

Back on main:

(lldb) print/d nz_i8
(core::num::nonzero::NonZeroI8) '\v' {
  __0 = 11
}
(lldb) expr/d nz_i8
(core::num::nonzero::NonZeroI8) $0 = 11 {
  __0 = 11
}

[kastiglione]

I can see one possible difference between expression and dwim-print. Is there a way to test this with C or C++?

[kastiglione]

Update: I have made myself a C++ based test case.

[kastiglione]

Here's what I know so far:

• expression defaults to printing a persistent result variable (ie $0, $1)
• conversely, dwim-print defaults to not printing a persistent result
• When print/d nz_i8 is run with the previous versions of lldb, the d format is being applied to the persistent result
• When print/d nz_i8 is run with the latest version of lldb, the d format is not being applied to the summary string

The last item seems to make some sense: a summary string can be arbitrary, so how could lldb apply a formatting to an unknown string?

However lldb seems to do exactly that (formatting the summary string) when producing a persistent result. I haven't looked into why the formatting would happen for persistent results but not otherwise.

Thoughts @jimingham?

[jimingham]

On Aug 29, 2023, at 1:37 PM, Dave Lee ***@***.***> wrote: Here's what I know so far: expression defaults to printing a persistent result variable (ie $0, $1) conversely, dwim-print defaults to not printing a persistent result When print/d nz_i8 is run with the previous versions of lldb, the d format is being applied to the persistent result When print/d nz_i8 is run with the latest version of lldb, the d format is not being applied to the summary string The last item seems to make some sense: a summary string can be arbitrary, so how could lldb apply a formatting to an unknown string?

This seemed odd to me as well, but that's not strictly what's happening. lldb is setting the formatting on the ValueObject that is being returned, and then when the code in the summary formatter does GetValue() for one of the child VO's the GetValue code checks up the VO hierarchy to see if any parent has a formatting options set, and finds the one set on the top level VO that holds the result. Then the formatter sticks the result in the summary string. So the summary isn't per se getting formatted, but the format intention is recorded in the VO that's passed to the formatter. Jim

…

However lldb seems to do exactly that (formatting the summary string) when producing a persistent result. I haven't looked into why the formatting would happen for persistent results but not otherwise. Thoughts @jimingham <https://github.com/jimingham>? — Reply to this email directly, view it on GitHub <#65076 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADUPVW2MFRIXUIYHZUZHGQTXXZHKHANCNFSM6AAAAAA4DFYPZI>. You are receiving this because you were mentioned.

[kastiglione]

lldb is setting the formatting on the ValueObject that is being returned, and then when the code in the summary formatter does GetValue() for one of the child VO's, the GetValue code checks up the VO hierarchy to see if any parent has a formatting options set, and finds the one set on the top level VO that holds the result.

so the bug is that this logic is happening only for persistent results?

If I run v/d instead of print/d I get the non-formatted output too. I don't think I made any changes to how v works. However this contradicts what @davidtwco said:

Using print or frame variable or any other command I've found doesn't seem to make a difference.