
Internship - gTrace: Dynamic instrumentation of Go programs
Job Description
Location : Paris or Rennes
Description
Go (Golang) powers the modern cloud. From Kubernetes and Docker to Containerd and gVisor, most of today's cloud-native technologies are built in Go.
Yet, despite being open-source, Go programs are notoriously hard to analyze or extend dynamically. You usually have to recompile them to modify behavior or collect runtime insights.
But what if you could observe and extend Go binaries while they're running, without touching their source code?
This internship focuses on gTrace, an internal research project that brings dynamic binary instrumentation to Go. Think of it as a way to inject observability, debugging, and new behaviors into Go programs at runtime, similar to what eBPF does for the kernel, and Frida at the user-space level.
Currently, gTrace exists as a working prototype developed over several years of internal R&D. Your mission is to help transform it into a robust, open-source-ready tool for the wider community.
You'll contribute to a project at the intersection of systems programming, Go runtime internals, and binary instrumentation.
What you will do
During this 6-month internship, you will:
-
Work directly on gTrace, an internal dynamic instrumentation framework for Go.
-
Design and implement key missing features to bring it to production quality.
-
Improve runtime stability, API usability, and integration with modern Go versions.
-
Collaborate with experienced engineers and researchers on systems-level tooling.
By the end of the internship, you'll have deep hands-on experience with Go internals, dynamic analysis techniques, and open-source tooling. You'll also have the opportunity to write a blog post (or why not series of blog posts?) which will be published on our blog and shared with our peers. Upon successful completion, you'll have the chance to present the tool at a conference.
Objective
The goal of this task is to develop a Go program that identifies and retrieves all asynchronous preemption safe points for all user-defined ("userland") functions from a compiled but not stripped Go binary.
The Go compiler embeds detailed runtime metadata in every compiled binary, including:
-
Function metadata (names, entry points, stack sizes, argument and return value counts).
-
Line tables (mapping program counters to source file lines).
-
Stack maps and garbage collection data for function arguments and local variables.
-
PCDATA and FUNCDATA tables that describe, among other things, safe points for garbage collection and asynchronous preemption
Task Description
1. Locate and parse the pcln table
Extract the pclntab structure from the binary and identify relevant function metadata:
-
_func entries (per-function metadata)
-
pclntab headers and offsets
-
Per-PC (program counter) data streams
Reference Material
2. Extract asynchronous preemption safe points
Use PCDATA channel information to determine preemption-safe locations within each function:
-
The PCDATA table is multi-channel; channel 0 encodes preemption safety status per program counter.
-
A value of $-1 (_PCDATA_UnsafePointSafe) indicates a safe preemption point.
-
A value of $-2 (_PCDATA_UnsafePointUnsafe) indicates an unsafe region.
Reference Material
3. Filter out non-application functions
Exclude Go runtime and standard library symbols to focus only on user-defined functions. This filtering can be performed before or after parsing safe points.
4. Generate structured output
Produce a well-defined output format (e.g., JSON) that includes:
-
Function name
-
Code address ranges
-
Corresponding source file and line number (if available)
-
Program counters of safe preemption points
Skills & Technologies
Company Info

Quarkslab
Deep tech software and data protection with offensive and defensive cybersecurity capabilities for g...
Other Jobs at Quarkslab
Similar Opportunities
Job Description
Location : Paris or Rennes
Description
Go (Golang) powers the modern cloud. From Kubernetes and Docker to Containerd and gVisor, most of today's cloud-native technologies are built in Go.
Yet, despite being open-source, Go programs are notoriously hard to analyze or extend dynamically. You usually have to recompile them to modify behavior or collect runtime insights.
But what if you could observe and extend Go binaries while they're running, without touching their source code?
This internship focuses on gTrace, an internal research project that brings dynamic binary instrumentation to Go. Think of it as a way to inject observability, debugging, and new behaviors into Go programs at runtime, similar to what eBPF does for the kernel, and Frida at the user-space level.
Currently, gTrace exists as a working prototype developed over several years of internal R&D. Your mission is to help transform it into a robust, open-source-ready tool for the wider community.
You'll contribute to a project at the intersection of systems programming, Go runtime internals, and binary instrumentation.
What you will do
During this 6-month internship, you will:
-
Work directly on gTrace, an internal dynamic instrumentation framework for Go.
-
Design and implement key missing features to bring it to production quality.
-
Improve runtime stability, API usability, and integration with modern Go versions.
-
Collaborate with experienced engineers and researchers on systems-level tooling.
By the end of the internship, you'll have deep hands-on experience with Go internals, dynamic analysis techniques, and open-source tooling. You'll also have the opportunity to write a blog post (or why not series of blog posts?) which will be published on our blog and shared with our peers. Upon successful completion, you'll have the chance to present the tool at a conference.
Objective
The goal of this task is to develop a Go program that identifies and retrieves all asynchronous preemption safe points for all user-defined ("userland") functions from a compiled but not stripped Go binary.
The Go compiler embeds detailed runtime metadata in every compiled binary, including:
-
Function metadata (names, entry points, stack sizes, argument and return value counts).
-
Line tables (mapping program counters to source file lines).
-
Stack maps and garbage collection data for function arguments and local variables.
-
PCDATA and FUNCDATA tables that describe, among other things, safe points for garbage collection and asynchronous preemption
Task Description
1. Locate and parse the pcln table
Extract the pclntab structure from the binary and identify relevant function metadata:
-
_func entries (per-function metadata)
-
pclntab headers and offsets
-
Per-PC (program counter) data streams
Reference Material
2. Extract asynchronous preemption safe points
Use PCDATA channel information to determine preemption-safe locations within each function:
-
The PCDATA table is multi-channel; channel 0 encodes preemption safety status per program counter.
-
A value of $-1 (_PCDATA_UnsafePointSafe) indicates a safe preemption point.
-
A value of $-2 (_PCDATA_UnsafePointUnsafe) indicates an unsafe region.
Reference Material
3. Filter out non-application functions
Exclude Go runtime and standard library symbols to focus only on user-defined functions. This filtering can be performed before or after parsing safe points.
4. Generate structured output
Produce a well-defined output format (e.g., JSON) that includes:
-
Function name
-
Code address ranges
-
Corresponding source file and line number (if available)
-
Program counters of safe preemption points
Skills & Technologies
Company Info

Quarkslab
Deep tech software and data protection with offensive and defensive cybersecurity capabilities for g...
