GSoC 2026: Question about FFI Type Metadata and Pointer<Never> in Dart VM

[kryxen]

I am Yaswanth, and I am interested in contributing to GSoC 2026 for the project  inspect Native Memory in Dart DevTools.

I know you are busy, so I will try to be brief and to the point.

Here is the Project Description for quick overview

Description: When using the Dart debugger on Pointer<X> (where X extends Struct or Union or is a native type), the pointer itself is opaque. It would be extremely useful if the debugger could inspect the memory that the Pointer points to, effectively making .ref available as an inspectable getter.

For example, when debugging the following code:

import 'dart:ffi';
import 'package:ffi/ffi.dart';

final class MyStruct extends Struct {
  @Int32()
  external int a;
  @Double()
  external double b;
}

void main() {
  final ptr = malloc<MyStruct>();
  ptr.ref.a = 42;
  ptr.ref.b = 3.14;
  // Inspecting 'ptr' in the debugger should allow seeing 'a' and 'b'
  // (either via the binary layout or a higher-level abstraction).
  malloc.free(ptr);
}

Currently, ptr only shows its memory address in the debugger.

However, dereferencing invalid pointers leads to segmentation faults. While nullptr (address 0) is easy to check, user-created pointers might point to invalid memory, and dereferencing them during a debug session should not crash the application.

From my understanding, the pointer type here should be Pointer<MyStruct>. However, when I inspected the type at runtime, it always appears as Pointer<Never>.

I assume that the generic type information is erased at runtime, and I could not find any layout metadata in the VM for the struct.

For this project, would I need to modify the VM to preserve and expose type and layout metadata for FFI objects? Or is this information already available in the VM and I may have missed it?

Also, is Pointer<Never> the expected runtime behavior?
I have also attached the relevant code. 

Thank you for your time.

[Daco Harkes]

Hi Kryxen!

Yes, we indeed erase the type argument. This is an optimization. We only want to rely on the static types when it comes to FFI.

In which contexts do we have the static type? We should have it in the expression evaluator. I don't know if we have it available when iterating the stack variables. Maybe @Ben Konyi knows. We definitely don't have it available when traversing the object graph without context.

> For this project, would I need to modify the VM to preserve and expose type and layout metadata for FFI objects?

We don't want to undo the optimization of erasing the runtime type information.

Some of the information should be available on the Struct classes with annotations. See runtime/vm/compiler/ffi/native_type.cc. So the only information we have is on types/classes. And pointers don't carry a type argument.

Kind regards,

 •  Daco Harkes
 •  Software Engineer
 •  dacoh...@google.com 

--
You received this message because you are subscribed to the Google Groups "dart-gsoc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dart-gsoc+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/dart-gsoc/cd72eff7-ab0b-4691-8832-ee7dbab2fe70n%40googlegroups.com.

[kryxen]

Thank you for the response, Daco.

I looked into the stack variables, but the type information does not appear to be present there.

Using the expression evaluator, I was able to retrieve native types; however, this does not seem to work for structs and unions.

I will continue exploring the VM code to determine whether there are alternative ways to obtain the type information. One possibility I am considering is passing the type information from the IDE to the VM.

Thank you again for your guidance.