Need some discussion forum

[synopse]

Where to discuss all this?

For instance, why reinvent a type system, whereas there is already one with the FPC RTTI.
There is no direct boolean support in your code if I am correct, you search for uppercase 'BOOL' in the type name if the integer size is 1 byte in the code I have seen. Not very clean.

This is a very nice idea for sure.

[graemeg]

GitHub Discussions is the right place - I'm glad to say, its enabled now. Bug reports and feature requests can
go in Issues as usual.

Why not FPC RTTI?

Good question! The short answer is that RTTI serves a different purpose -- it's designed for the running process to query
its own types at runtime. A debugger is a separate process observing from the outside via ptrace, and needs things RTTI
doesn't provide: local variables with stack offsets, scope information, source line mappings, private fields, and property
getter metadata. OPDF is purpose-built to carry all of that in an ELF section with addresses resolved at link time.

Boolean handling - fair point!

You're absolutely right, the Pos('BOOL', UpperCase(TypeInfo.Name)) approach is a heuristic and not clean at all. The
recPrimitive record in OPDF currently only carries size and signedness -- there's no semantic subkind to distinguish Boolean
from Integer from Char.

The proper fix is adding a subkind byte to recPrimitive in the OPDF spec (e.g. 0=integer, 1=boolean, 2=char) and emitting
it from the compiler. That's on the roadmap. The name-matching was a pragmatic shortcut to get boolean display working
early -- it works because FPC's type names are well-known, but I agree it is not clean and will be replaced. Thanks for reminding me to clean that up!

[graemeg]

The recPrimitive change was pretty small, and I'm happy to report it's been cleaned up. Sub-kinds are now supported

https://github.com/graemeg/opdebugger/blob/master/docs/feature-specs.adoc#feature-17-primitive-subkind-byte

[synopse]

Nice to be able to discuss this.

Now, recPrimitive is very close to the typinfo.pp type layout, so it is great improvement!

Another topic: from the specs, the exact floating point registers support is not defined.
The compiler usually put floats into XMM registers on x86_64, and the debugger should be able to inspect those - not only the main Rxx registers.
Both for the ABI, and for the local / transient variables.

[synopse]

Another note:

When you will implement variants, don't forget about custom variant type support. We use it very much with our TDocVariant JSON document holder, and there is already support in fpdebug for runtime display of such values.
I guess there is no specific need of support in the opdf format, but the ability to let the debugger handle this at runtime. So opdebugger should be able to do the same as fpdebug in this respect.
We also sponsored advanced JSON parsing/display in fpdebug for such values, which is very nice to have in a debugger.

[graemeg]

When you will implement variants, don't forget about custom variant types support.

It's not forgotten, and already listed in the progress document as Feature 10 and 10b.. 🙂 I'm almost ready to pick that up.

If you have any specific use case or code example, that would be very useful during my implementation.