How to contribute?

51 views
Skip to first unread message

Kwesi Frempong-Smart

unread,
Oct 6, 2025, 1:02:26 PM (14 hours ago) Oct 6
to golang-nuts
I have used Go for a while now, I am currently learning x86-64 asm, and would love to see how things work on the language/toolchain side. Also possibly contribute.

How can I get started with this? Any beginner-friendly guides to understanding the language internals or how to contribute? How do I start reading the Go language code since there is no main function (I suppose)?

Jason E. Aten

unread,
Oct 6, 2025, 7:03:03 PM (8 hours ago) Oct 6
to golang-nuts
Other folks will have better answers, but you can read


to get some basic info.

You could look at the open bugs and try to work one. (https://github.com/golang/go/issues )

It might help to describe a little more the kinds of things that you are
interested in -- you might get better guidance.

For assembly-like stuff, I seem to recall that Evan (Phoenix) and 
Johan (Brandhorst-Satzkorn)'s work on the next 
Go-to-WebAssembly (WASM) compiler iteration might
be a bit stalled -- though my information
is almost certainly out of date. You might talk to them about
where they are at with it. See 

and 

and the #webassembly and #contributing channels on the Gopher's Slack.

Jason E. Aten

unread,
Oct 6, 2025, 7:55:05 PM (7 hours ago) Oct 6
to golang-nuts
Actually, it occurs to me that this bug I filed would be perfect for someone 
who can read x86-64 assembly (I'm pretty bad at it). 

It might be a great first issue if you're interested in 
how the Go runtime works in that

a) it has several perfect reproducers 

-- by using the rr-debugger on amd64 and recorded 
executions and hardware watchpoints
you can play the crashes forwards and backwards in time;
and have rr (gdb) pinpoint exactly where the memory corruption occurs.

See the recordings available here 


b) it will teach you alot about the Go runtime (initialization
in particular); and

c) it seems to need the ability to read assembly.

Jason E. Aten

unread,
Oct 6, 2025, 8:06:17 PM (7 hours ago) Oct 6
to golang-nuts
> using the rr-debugger on amd64 and recorded 
executions and hardware watchpoints
you can play the crashes forwards and backwards in time;
and have rr (gdb) pinpoint exactly where the memory corruption occurs.

If this is a new idea, to understand the rr (record and
replay deterministically) approach to debugging,
the following youtube video is a great teacher/example. 

Even though it does not use rr itself -- it does
use the exact same principles: deterministic replay, 
running your execution trace backwards to where
the hardware watchpoint is hit. It gives a nice relatable 
and visual demonstration inside a game development 
environment which makes it easy to follow.

Reply all
Reply to author
Forward
0 new messages