Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We found a bug in Go's ARM64 compiler

blog.cloudflare.com

Post reply on HN
Print view View original

11–20 of 146 posts

Re: We found a bug in Go's ARM64 compiler

#11

Post by nevon »

jgrahamc wrote: post #10
Agingcoder wrote: post #6

Excellent article as always from the cloudflare blog - engineering without magic infrastructure and ml. One day I will apply ! Compiler bugs are actually quite common ( I used to find several a year in gcc ), but as the author says, some of them only appear when you work at a very large scale, and most people never dive that far.

What's stopping you applying today?

Similar to the previous commenter, every time I read a blog post from Cloudflare I end up checking the careers page thinking "this is exactly the kind of work I'd like to be doing". Sadly no openings in my country. I'll keep checking!

Re: We found a bug in Go's ARM64 compiler

#14

Post by whizzter »

dreamcompiler wrote: post #7

Always adjust your stack pointer atomically, kids.

I guess those that wrote the preemption were on X86 where this doesn't happen thanks to variable length instructions being able to hold the constant and thus relied on the code-gen to do it atomically, then the ARM port had an automatic "split" from a higher level to make things "easy" thus giving us this bug.

Nobodys fault really, but bad results ensued.

Re: We found a bug in Go's ARM64 compiler

#15

Post by Neywiny »

bloak wrote: post #5
Neywiny wrote: post #3

That's an incredible find and once I saw the assembly I was right along with them on the debug path. Interestingly it doesn't need to be assembly for this to work, it's just that that's where the split was. The IR could've done it, it just doesn't for very good reasons. So another win for being able to read arm assembly. Unsure if this would be another way to do it but to save an instruction at the cost of a memory a…

> So another win for being able to read arm assembly. Yes, though that weird stuff with dollars in it is not normal AArch64 assembly! The article could have mentioned the "stack moves once" rule.

I've never heard of that rule (though tbh I'm not allocating > 64KB of stack when I'm in assembly) and it seems Google hasn't either. While I'm sure it makes sense, I don't think I've ever seen that be enforced. At least in C/C++. Maybe it makes more sense for these stack inspecting garbage collectors but I've also heard of ones that just scan the stack without unwinding anything. I did a test asking Google's AI to generate a complicated C function, put it in godbolt, and there's plenty of push push push push ..... Pop Pop Pop Pop going on

Re: We found a bug in Go's ARM64 compiler

#16

Post by andygocke »

pjmlp wrote: post #9
Neywiny wrote: post #3

That's an incredible find and once I saw the assembly I was right along with them on the debug path. Interestingly it doesn't need to be assembly for this to work, it's just that that's where the split was. The IR could've done it, it just doesn't for very good reasons. So another win for being able to read arm assembly. Unsure if this would be another way to do it but to save an instruction at the cost of a memory a…

Usually in runtimes like Java and .NET there are safepoints exactly to avoid changing context in the middle of a set of instructions.

Yeah but we have codegen bugs in .NET as well. The biggest difference that stood out to me in this write up, is we would have gone straight for “coredump” instead of other investigation tools. Our default mode of investigating memory corruption issues is dumps.

Re: We found a bug in Go's ARM64 compiler

#18

Post by moomoo11 »

nevon wrote: post #11
jgrahamc wrote: post #10

Earlier quoted context omitted.

What's stopping you applying today?

Similar to the previous commenter, every time I read a blog post from Cloudflare I end up checking the careers page thinking "this is exactly the kind of work I'd like to be doing". Sadly no openings in my country. I'll keep checking!

Pretty sure location is not a factor for these companies. You should apply anyway. I’ve worked with people living in active war zones.

If you have the skills, they have the coin.

They won’t hire some react guy in X country but someone who can find compiler bugs and save them XX+ million dollars a year? Heck yeah.

Re: We found a bug in Go's ARM64 compiler

#19

Post by renewiltord »

Great technical blog. Good pathway for narrative, tight examples, description so clear it makes me feel smarter than I am because so easy to follow though the last time I even read assembly seriously was x86 years ago.

Also, fulfills the marketing objective because I cannot help but think that this team is a bunch of hotshots who have the skill to do this on demand and the quality discipline to chase down rare issues.

I assume these are Ampere Altra? I was considering some of those for web servers to fill out my rack (more space than power) but ended up just going higher on power and using Epyc.

Re: We found a bug in Go's ARM64 compiler

#20

Post by cmckn »

pengaru wrote: post #12

For the impatient, here's the fix: https://github.com/golang/go/commit/f7cc61e7d7f77521e073137c...

I noticed this when reviewing the linked issue: https://github.com/golang/go/issues/73259#issuecomment-31004...

Does the Go team have a natural language bot or is this just comment.contains(“backport”) type stuff?

Post reply on HN