python support

[pelletier]

Draft changes to support stack walking and symbolization for Python guests to provide meaningful profiles for python scripts.

Limitations: only support CPython3.11 (testing against https://github.com/stealthrocket/timecraft/tree/main/python), which is built with debug symbols.

Refs #64

TODO

• Detection of Python.
• Detect and constraint version of Python.
• Basic python stack walking.
• Find the right functions to instrument (_PyEvalFramePushAndInit triggers twice).
• Add module information.
• Memory allocations.
• Tests.
• Update README.

Stretch

• Python: defer symbolization #96
• Python: write a tool to generate struct offsets #97
• Python: walk and merge the C extension call stack #98
• Python: add column information #99

---

[achille-roussel]

Could we add a stricter constraint to the type parameter?

[pelletier]

What do you have in mind?

[achille-roussel]

Maybe a constraint like:

type dereferenceable interface {
  ~ptr32 | ~ptr64 | // etc...
}

I imagine there are types that would not be valid to pass (e.g. things containing inner pointers), so the compiler could help us validate that if we are more strict.

[pelletier]

I use deref on struct types. Is there a way to express a type constraint of structs only made of dereferenceable types?

otherwise the full type set is

type derefable interface {
	~int32 | ~int64 | ~uint32 | ~uint64 | ~byte | findfuncbucket | moduledata | functab | textsect | inlinedCall
}

[pelletier]

I will put the stretch action items into separate GitHub issues to open them up for contributions.

@achille-roussel since deref was already in the code I don't think missing a type constraint for it is a blocker for this change. That said I'd love to learn how to add it, so let's continue the discussion in this thread and will open a new pull request when we figure out a good way forward.