Classic problem of non-atomic stack pointer modification.
Used to have a lot of fun with those 3 decades ago.
We found a bug in Go's ARM64 compiler
51–60 of 146 posts
Re: We found a bug in Go's ARM64 compiler
#52Earlier quoted context omitted.
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.
> Nobodys fault really, but bad results ensued. Uh, the fault is entirely in writing an assembler _that is not an assembler_, but rather something that is _almost_ like one but then 1% like an IR instead. It's an unforced error.
Assemblers used to do a ton of stuff back in the day
Re: We found a bug in Go's ARM64 compiler
#53Earlier quoted context omitted.
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.
Unfortunately, in 95% cases location IS a factor with bigger companies. I'm in a similar position where I'd like to do something a lot more interesting, but intersection between where the interesting companies have offices and where I'd be willing to live do not really overlap enough justify rooting up my life. (Unless we're talking about "too good to ignore", that's a different story.)
I was explicitly talking about too good to ignore.
Anyone who can optimize a company’s bottom line will be hired.
Like I said, no random average mid react guy or dime a dozen Java developer is getting hired as a remote employee in some flyover country.
But if someone can provide like 50x value then hell yeah..
I thought that was obvious in my message considering we are discussing compiler optimization
Re: We found a bug in Go's ARM64 compiler
#54Excellent 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?
Fair question. Location primarily ( nothing in France ), and I’m not sure how ‘we’re looking for people who enjoy doing that kind of thing’( I very much do ) relates to the actual job offers, ie what job offer should I actually apply to.
My background is not networking ( it’s math then hpc then broader stuff ) but I keep stumbling on similar problems ( including a beautiful one related to intel NICs a few years ago which led be into a rabbit hole of ebpf and kernel network layer and which surfaced later on the cloudflare blog), and the only tech company with which this seems to be a regular occurrence is cloudflare. Their space is a bit unknown to me so I guess I’m having a hard time projecting something onto the job offers.
I’d happily chat to someone working for cloudflare though - I guess this would help me understand what it is that actually happens over there. I guess I’m a bit intimidated by this unknown yet really good looking world :-)
Re: We found a bug in Go's ARM64 compiler
#55> This was a very fun problem to debug. I'm sure it was a relief to find a thorough solution that addressed the root cause. But it doesn't seem plausible that it was fun while it was unexplained. When I have this kind of bug it eats my whole attention. Something this deep is especially frustrating. Nobody suspects the standard library or the compiler. Devs have been taught from a young age that it's always you, not t…
It feels like this comment was almost a purely additive anecdote of your own experience with a similar kind of issue, but you've spoiled it by deciding to tell the author that they're incorrect about how they felt during the process? Maybe different people find different things fun.
Not saying he's wrong, sometimes the word "fun" connotes something slightly different what what it literally means. "Satisfying" is something I'd use for the end state. Maybe "challenging" for the intermediate state. But while you're in a high-pressure situation that you don't understand, that is rarely "fun" in the literal sense.
You wouldn't pay to be given compiler race condition bugs, right?
Re: We found a bug in Go's ARM64 compiler
#56Earlier quoted context omitted.
It feels like this comment was almost a purely additive anecdote of your own experience with a similar kind of issue, but you've spoiled it by deciding to tell the author that they're incorrect about how they felt during the process? Maybe different people find different things fun.
Not saying he's wrong, sometimes the word "fun" connotes something slightly different what what it literally means. "Satisfying" is something I'd use for the end state. Maybe "challenging" for the intermediate state. But while you're in a high-pressure situation that you don't understand, that is rarely "fun" in the literal sense. You wouldn't pay to be given compiler race condition bugs, right?
Maybe stop digging here and just let it be fun for the author?
Re: We found a bug in Go's ARM64 compiler
#57> This was a very fun problem to debug. I'm sure it was a relief to find a thorough solution that addressed the root cause. But it doesn't seem plausible that it was fun while it was unexplained. When I have this kind of bug it eats my whole attention. Something this deep is especially frustrating. Nobody suspects the standard library or the compiler. Devs have been taught from a young age that it's always you, not t…
> I'm sure it was a relief to find a thorough solution that addressed the root cause. But it doesn't seem plausible that it was fun while it was unexplained. When I have this kind of bug it eats my whole attention.
Hey; it could've been type-3 fun.
Re: We found a bug in Go's ARM64 compiler
#58Earlier quoted context omitted.
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?
The latter: https://github.com/golang/build/blob/master/cmd/gopherbot/go... (found via https://go.dev/wiki/gopherbot )
Kinda funny that it requires both "please" and "backport" for it to be considered haha.
Re: We found a bug in Go's ARM64 compiler
#59> This was a very fun problem to debug. I'm sure it was a relief to find a thorough solution that addressed the root cause. But it doesn't seem plausible that it was fun while it was unexplained. When I have this kind of bug it eats my whole attention. Something this deep is especially frustrating. Nobody suspects the standard library or the compiler. Devs have been taught from a young age that it's always you, not t…
It becomes fun when you narrow down to the solution. Before that it's hell.
I don't think I'd be allowed spend weeks to debug something like this. Credit to Cloudflare's PMs.
Re: We found a bug in Go's ARM64 compiler
#60I don't get it, how were the machine threads being stopped in thr middle of two instructions? This is baremetal, right?
Signals.