print pointer value of pointer expressions

[lfolger]

What version of Delve are you using (dlv version)?

$ dlv version
Delve Debugger
Version: 1.21.0
Build: $Id: fec0d226b2c2cce1567d5f59169660cf61dc1efe $

What version of Go are you using? (go version)?

go version built from HEAD

What operating system and processor architecture are you using?

linux/amd64

What did you do?
Compile https://go.dev/play/p/Sth1ADkMLj5

dlv exec path/to/binary
(dlv) b main.go:14
(dlv) c
[omitted output]
(dlv) p i
*0
(dlv) p t
*main.T {a: 0}

What did you expect to see?

dlv exec path/to/binary
(dlv) b main.go:14
(dlv) c
[omitted output]
(dlv) p i
(int*) 0x000abc120 = 0
(dlv) p t
*main.T 0x000def4560 {a: 0}

I would like to see the actual pointer value of a pointer based expression in addition the the pointed-to value as I suggested in the What did you expect to see?. I don't mind the concrete formatting but printing the concrete pointer value would be a great addition.

For pure variables you can work around this by using something like p %x uintptr(var) but this does not work for arbitrary expression or interfaces.

[aarzilli]

Something like this was already done in #3448 (weird that we'd have two requests for the same feature a week apart).
However:

For pure variables you can work around this by using something like p %x uintptr(var) but this does not work for arbitrary expression or interfaces.

I don't understand what this means. It should indeed work for arbitrary expressions or interfaces.

[lfolger]

When I tried debugging an unrecovered panic I faced the follow problem after going up the stack several layers:

(dlv) c
... <panic>
(dlv) up
...
(dlv) up
(dlv) p n
[redacted]/dst/dst.Node(*[redacted]/dst/dst.ImportSpec) *{
        Name: *[redacted]/dst/dst.Ident nil,
        Path: *[redacted]/dst/dst.BasicLit {
                ...
        Decs: [redacted]/dst/dst.ImportSpecDecorations {
                ...,}
(dlv) p %x uintptr(n)
Command failed: can not convert "n" to uintptr

n is a dst.Node (interface type).

This is what I meant with "does not work in all contexts". I'm not sure if this is a bug or intented behavior but something that means the work around does not work in all cases.

[aarzilli]

p %x uintptr(n.(data))

[lfolger]

Thanks. This seems to work. Is this documented somewhere?

Anyway, I still think this would not be needed if delve would just print the pointer value by default.

[aarzilli]

Thanks. This seems to work. Is this documented somewhere?

https://github.com/go-delve/delve/blob/master/Documentation/cli/expr.md#interfaces

Anyway, I still think this would not be needed if delve would just print the pointer value by default.

The next version of delve will print it with just p n.(data), we also don't want the output of print to become too busy and hard to understand.

[lfolger]

Just to be clear. This issue is primarily about expressions of pointer type not interfaces.

Do I understand your last comment correctly that you are rejecting this feature request?

I think it is the wrong default to not print the pointer value of an expression pointer type (not interface). I think this is inconsistent with how e.g. fmt.Printf with %v works which prints the pointer value. It is also incosistent with other debuggers that print the pointer value and only if you dereference the expression, they print the pointed-to value.

I don't think that adding the pointer value to the output makes the output to busy because for scalar types the output is already only a single line and it would stay a single line.
For struct types the output is usually quite long already due to the fully qualified type name. Adding a single pointer value barely increases the size of the output but provides valuable information.

I think printing the pointer value and the pointed-to value be default is correct and users don't want to have the pointer value they can dereference the expression to only get the pointed to value.

[lfolger]

Looking at the other issue it seems this was already implemented.
I understood your last comment as: "There are work arounds. Closing this issue".

Thanks and sorry for the noise.