Relatedly: does anyone know offhand what x86-64 instruction sets FTZ/DAZ? I need to objdump and grep all my libraries to figure out who's doing it.
Brendan Dolan-Gavitt @moyix
30 Aug 2022
[Three Little Bears voice] Someone's been messing with my subnormals! 😡
2
1
4
Oh god oh no there's more than one loaded into this process. OK, next question, is it possible to trap when ldmxcsr is executed? Or am I going to have to make an *awful* gdb breakpoint script from this output?
Kyle Huey @khuey_
30 Aug 2022
Replying to @moyix
LDMXCSR
3
4
No there's no way to trap on that instruction. If you don't need an answer tonight I could rig up something to get the answer in Pernosco.
1
1
I don't need it to night (this has been going on for a while and it's harmless AFAICT (some library got compiled with -ffast-math), just annoying). Sadly I don't have Pernosco though!
1
It's a website that's available to randos now.
1
1
Ooh I hadn’t looked in a while, I’ll check it out
1
I don't have any handling for MXCSR right now but this is the second time somebody has wanted to know wtf set one of those flags (first was @davidbaron). Time to add something for it perhaps.
1
1
Replying to @khuey_ @moyix
I was able to figure out what changed MXCSR once I knew that was the problem. I don't remember how I did it, but maybe it helped that in my case it was a push/pop change that was on the assertion failure's stack, so I could just go up the stack in gdb+rr. bugs.chromium.org/p/chromium…

Aug 30, 2022 · 2:38 PM UTC

1
1
Replying to @davidbaron @moyix
You narrowed it down to a relatively small time period somehow and then used `watch $mxcsr` in the embedded gdb which is super slow (it'll singlestep). But I should teach Pernosco how to track MXCSR values the same way it can track GPRs and memory.
2