Debugging an evil Go runtime bug

#1

Post by cmsimike » Mon, Dec 04, 2017, 4:34 PM UTC

Debugging an evil Go runtime bug
marcan.st

Re: Debugging an evil Go runtime bug

#2

Post by cwzwarich » Mon, Dec 04, 2017, 6:14 PM UTC

Why doesn't the vDSO code just use MOV in its stack probe probe rather than an OR?

Re: Debugging an evil Go runtime bug

#3

Post by rocqua » Mon, Dec 04, 2017, 6:28 PM UTC

cwzwarich wrote: post #2

Why doesn't the vDSO code just use MOV in its stack probe probe rather than an OR?

My best guess would be to prevent the 'useless instruction' from being optimized out, but an or with 0 is still useless, and I don't see what optimizer lies between this GCC feature and the final binary.

Maybe the segfault only occurs on a write?

Re: Debugging an evil Go runtime bug

#4

Post by jicks » Mon, Dec 04, 2017, 7:00 PM UTC

cwzwarich wrote: post #2

Why doesn't the vDSO code just use MOV in its stack probe probe rather than an OR?

Apparently, because it's shorter [0].

[0]: See https://lkml.org/lkml/2017/11/10/348

Re: Debugging an evil Go runtime bug

#5

Post by cwzwarich » Mon, Dec 04, 2017, 7:22 PM UTC

jicks wrote: post #4

cwzwarich wrote: post #2

Why doesn't the vDSO code just use MOV in its stack probe probe rather than an OR?

Apparently, because it's shorter [0]. [0]: See https://lkml.org/lkml/2017/11/10/348

Why is it shorter? Both MOV and OR have one byte encodings, and with the OR you either have to use an immediate zero (which burns a byte) or materialize zero in some other way. As that email points out, the entire sequence would be shorter using a different addressing mode anyways. And a read-modify-write is definitely slower at runtime.

Re: Debugging an evil Go runtime bug

#6

Post by dmitshur » Mon, Dec 04, 2017, 7:36 PM UTC

The investigation in the linked Go issue [1] is also impressive.

[1] https://github.com/golang/go/issues/20427

Re: Debugging an evil Go runtime bug

#7

Post by smegel » Mon, Dec 04, 2017, 7:49 PM UTC

dmitshur wrote: post #6

The investigation in the linked Go issue [1] is also impressive. [1] https://github.com/golang/go/issues/20427

Don't forget about this one, similar but affects BSD and still open:

https://github.com/golang/go/issues/15658

Re: Debugging an evil Go runtime bug

#8

Post by fierro » Mon, Dec 04, 2017, 7:52 PM UTC

this is incredibly impressive

Re: Debugging an evil Go runtime bug

#9

Post by MrBuddyCasino » Mon, Dec 04, 2017, 8:19 PM UTC

fierro wrote: post #8

this is incredibly impressive

That was Captain Ahab level persistence. I wonder how long it took him.

Re: Debugging an evil Go runtime bug

#10

Post by warent » Mon, Dec 04, 2017, 8:50 PM UTC

Marcan's attitude is great; I know of a ton of people (myself included) who would've written that article with far more complaining interleaved. Super informative as well, I learned a ton from this article (GRUB 2 feature for marking off bad RAM? Wow!). Very well written, informative, humorous, etc. Love it