On Wed, Jan 18, 2023 at 5:33 AM Feng Tang <feng.tang@xxxxxxxxx> wrote: > > > Finally, your objdump version also does some horrendous decoding, like > > > > c13b3e29: 8d b4 26 00 00 00 00 lea 0x0(%esi,%eiz,1),%esi > > I know little about these tools, and I tried objdump tool from > Cent OS 9 (objdump version 2.35.2) and Ubuntu 22.04 (objdump version > 2.38), they both dumped similar assembly. Please let me know if you > want us to try other version of objdump. It's fine - it just makes things even less legible than they already were. I personally very seldom try to look at objdump output - I tend to do things like make mm/page_alloc.s and look at the compiler-generated assembly instead. That ends up generally being a lot more legible for various reasons, not the least of which is the variable name commentary that the compiler also outputs. So objdump is kind of a last resort, and then you just have to deal with the fact that its output format is very nasty. > We modify the kconfig to disable GCOV and UBSAN, and the issue can't > be reproudced in 1000 runs. Ok, it does seem like this is a compiler bug, as per Vlastimil's decoding. And the reason it happens on 32-bit is probably that we just have much fewer registers available there, and the 64-bit GCOV counts then complicate things even more, and then some interaction between that and UBSAN just generates crazy code. And it probably has very little compiler test coverage in real life anyway. >From Vlastimil's decode, it does look like gcc has mixed up the "update GCOV counts" with actual real values for "nr_pages", and is using %eax for both things because of some register allocation mistake. So I think we can dismiss this one as a compiler bug. It might be good to see if it happens with a newer version of gcc too, and even perhaps post a gcc bugzilla entry, but since this probably isn't really a very interesting config for real life, I'm not sure how interested people are going to be. Linus