On Wed, Jan 18, 2023 at 09:10:45AM -0800, Linus Torvalds wrote: > 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. Just tried this, the generated assembly is much more readable, thanks for the tip! > 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. Yes. > 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. I guess the O1/O2 difference is also the 'fewer registers' case, that O1 make many functions not inlined into prep_compound_page() and needs less registers. > 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. I tried to file a gcc bug, but was stuck in creating account phase, will follow up. I don't know if it makes sense to make GCOV_KERNEL option depend on !X86_32 for now, till the problem is solved. Or we can ask 0Day to disable GCOV for i386 build, assuming GCOV+i386 is not a common usage model. Thanks, Feng > Linus >
