How to contribute?

250 views
Skip to first unread message

Kwesi Frempong-Smart

unread,
Oct 6, 2025, 1:02:26 PMOct 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 PMOct 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 PMOct 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 PMOct 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.

Kwesi Frempong-Smart

unread,
Oct 8, 2025, 7:15:41 AM (13 days ago) Oct 8
to golang-nuts
Thanks for the pointers!

It will definitely take me some time to do this, but i'll look into it

HARD. Nurtai

unread,
Oct 9, 2025, 1:11:45 PM (12 days ago) Oct 9
to golang-nuts

Your issue is open since June. Is there anyone working on it?
вторник, 7 октября 2025 г. в 04:55:05 UTC+5, Jason E. Aten:

Jason E. Aten

unread,
Oct 9, 2025, 1:26:34 PM (12 days ago) Oct 9
to golang-nuts
On Thursday, October 9, 2025 at 6:11:45 PM UTC+1 HARD. Nurtai wrote:

Your issue is open since June. Is there anyone working on it?

Not that I know of. Please have a go if you have the skills. It's a
blocker for stuff I'd really like to do (use rr record and replay more). 
Reply all
Reply to author
Forward
0 new messages