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

31–40 of 146 posts

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

#31

Post by JdeBP »

Neywiny wrote: post #15
bloak wrote: post #5

Earlier quoted context omitted.

> 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 g…

You need to look at non-x86 architectures. It was common years ago on MIPS.

* https://jdebp.uk/FGA/function-perilogues.html#StandardMIPS

I wrote up the x86 equivalent of doing just two read-modify-write operations on the stack pointer over 16 years ago.

* https://jdebp.uk/FGA/function-perilogues.html#Standardx86

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

#32

Post by stronglikedan »

moomoo11 wrote: post #18
nevon wrote: post #11

Earlier quoted context omitted.

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.

With seemingly the whole world rolling out new RTO mandates, location may not have been a factor recently, but may be lately.

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

#36

Post by [deleted] »

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.

[deleted]

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

#37

Post by themafia »

gok wrote: post #17

The real lesson here should be that doing crazy shit like swizzling the program counter in a signal handler and writing your own assembler is not a good idea.

Neither of those are "crazy shit." It's just complex because the environment offers specific features like automatic GC with async preemption in a compiled language which pretty much requires it.

Complex engineering isn't something to be avoided by default.

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

#40

Post by wat10000 »

mperham wrote: post #34
wat10000 wrote: post #27

I would have thought that unwinding would use the frame pointer and this wouldn't be a problem.

The frame pointer was updated non-atomically in two asm ops. An async interruption between the two ops would lead to a corrupt frame pointer.

So it was. The article never mentions the frame pointer and I'm familiar with compilers that load the saved value from the stack in the epilog, rather than adjusting it arithmetically. But they do have an assembly listing showing the two-step arithmetic adjustment for both the stack pointer and frame pointer.

But I'm not sure that matters, because the unwind code they show uses the stack pointer rather than the frame pointer anyway.

Post reply on HN